Detailed Action
This office action is in response to applicant’s submission filed on January 21, 2026. Claims 1-20 are pending and rejected.
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 Amendment
This communication is in response to the amendment filed on January 21, 2026. The Examiner has acknowledged the amended claims 1, 9, and 15. Claims 1-20 are pending and are rejected.
Response to Arguments
Applicant’s Arguments (Remarks) filed January 21, 2026 have been fully considered, but are moot. Note that this action is made FINAL. See MPEP § 706.07(a).
Applicant’s arguments with respect to claims 1, 9, and 15 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. See also 103 rejection below.
Therefore, Examiner notes that the amended claim limitations are still taught by Andrews and Jaiswal.
The amendments to claim 9 has resolved the claim objection.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 8-9, and 15 are rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0136082 A1 to Andrews et al. (hereinafter, “Andrews”) in view of US 2022/0337590 A1 to Jaiswal et al. (hereinafter, “Jaiswal”).
Regarding claim 1, Andrews discloses: A method for secure onboarding of an Information Handling System (IHS), the method comprising:
providing a rendezvous service of an onboarding system with an address of an onboarding service and a token that are both to be provided to the IHS (“Web services 306 that may be used in support of workspaces may further include resource provisioning services 312 for configuring an IHS or workspace with secrets/credentials necessary to access specific resources (e.g., credentials for use of VPNs, networks, data storage repositories, workspace encryption, workspace attestation, and workspace-to-device anchoring). In some cases, resource provisioning services 312 may include secrets provisioned as part of a trusted assembly process of IHS 300B and, in some instances, associated with a unique identifier 348 of the IHS 300B. In certain embodiments, resource provisioning service 312 may support multi-level authentication of workspaces 331A-N operating on IHS 300B. For instance, resource provisioning service 312 may provide IHS 300B with certificates and other cryptographic information for use in authenticating the hardware in use by IHS 300B, the configuration of IHS 300B for use of workspaces and the workspaces sessions deployed for operation by IHS 300B. Web services 306 may also include an authorization/token module that provides identity functions and may be connect to various authentication sources, such as, for example, Active Directory. Endpoint registration module 314 may be configured to register IHSs and/or workspaces with a management service that tracks the use of the described workspace orchestration. In some scenarios, a directory services 315 module may be configured to provide active directory services (e.g., AZURE ACTIVE DIRECTORY from MICROSOFT CORPORATION). Device configuration services 316 enable central configuration, monitoring, managing, and optimization of workspaces that in certain contexts may operate remotely from an IHS and may only present the user of the IHS with an image of the workspace output. In cooperation with resource provisioning services 312, device configuration services 316 may also handle secret creation and IHS configuration, and it some cases, may be out-of-band capable and handle selected operations to the endpoint” [0075-0076] [Examiner notes that the web services 306 describes the collection of cloud or enterprise services that support onboarding. The resource provisioning service 312 and endpoint registration module 314 are effective the "rendezvous" and "onboarding" infrastructure. They enable devices to locate, register, and communicate with the correct service when powered on. The directory service 315 and related management components maintain the network or directory information (addresses, endpoints, domains) that devices use to reach the onboarding service. The text also points out the creation and provisioning of tokens, secrets, and certificates. It also states that the provisioning service provides credentials to the IHS]);
powering the IHS for a first time upon a transfer of the IHS to an owner (“In certain embodiments, the configuration certificate 420 digest may specify settings and other information used to configure IHS 430 for participation in a particular workspace ecosystem. In some embodiments, the configuration certificate 420 may include an inventory ID that uniquely identifies the IHS 430 within a particular workspace ecosystem, such as a workspace ecosystem configured for use by employees or other affiliates of a particular enterprise. The configuration certificate may also include a workspace policy that specifies various settings for the participation of IHS 430 in the workspace ecosystem that is associated with the enterprise issuing the configuration certificate 420. For example, the workspace policy may specify settings for securely booting IHS 430, disk encryption to be used by IHS 430, network settings, and user authentication. In certain instances, configuration certificate 420 may also specify a key used in generating the hardware reference measurements included in the IHS certificate 415. The configuration certificate 420 may also identify a specific user that is authorized to utilize the workspace ecosystem via IHS 430. The user may be identified via credentials associated with the user, which may include biometric credentials used to identify a user” [0124] [Examiner notes that the transfer corresponds to the device being issued to the enterprise user or employee. The "workspace ecosystem" represents the owner's domain or environment into which the device is being onboarded. When the IHS is first powered on, this configuration certificate is read or activated to initialize the IHS with owner-specific settings. The first boot uses the configuration certificate to uniquely identify the device to the owner's ecosystem. The disk encryption, network settings, and user authentication are the configuration parameters applied during the first power on sequence when the IHS initializes under its new owner's control. Establishing the authorized user at first boot is the culmination of the transfer-to-owner concept]);
upon the first powering of the IHS, initiating, by the IHS, a connection with the rendezvous service of the onboarding system (“As illustrated, a variety of resources may be coupled to processor(s) 101 of IHS 100 through chipset 103. For instance, chipset 103 may be coupled to network interface 109, such as provided by a Network Interface Controller (NIC) that is coupled to the IHS 100 and allows the IHS 100 to communicate via a network, such as the Internet or a LAN. Network interface device 109 may provide IHS 100 with wired and/or wireless network connections via a variety of network technologies, such as wireless cellular or mobile networks (CDMA, TDMA, LTE etc.), WIFI and BLUETOOTH. In certain embodiments, network interface 109 may support connections between a trusted IHS component, such as trusted controller 115, and a remote orchestration service. In such embodiments, a connection supported by network interface 109 between the remote orchestration service and the trusted component may be considered an out-of-band (00B) connection that is isolated from the OS of the IHS” [0028] [Examiner notes that the IHS has a trusted controlled + NIC capable of initiating secure, out-of-band connections (establishes a connection to a remote service). This text proves that the IHS can initiate the connection to a remote service including the rendezvous service (endpoint registration module 314 in text)]);
providing, by the rendezvous service, the IHS the token and the address of the onboarding service, wherein the onboarding service is operated on behalf of the owner (“Web services 306 may also include an authorization/token module that provides identity functions and may be connect to various authentication sources, such as, for example, Active Directory. Endpoint registration module 314 may be configured to register IHSs and/or workspaces with a management service that tracks the use of the described workspace orchestration. In some scenarios, a directory services 315 module may be configured to provide active directory services (e.g., AZURE ACTIVE DIRECTORY from MICROSOFT CORPORATION). Device configuration services 316 enable central configuration, monitoring, managing, and optimization of workspaces that in certain contexts may operate remotely from an IHS and may only present the user of the IHS with an image of the workspace output. In cooperation with resource provisioning services 312, device configuration services 316 may also handle secret creation and IHS configuration, and it some cases, may be out-of-band capable and handle selected operations to the endpoint” [0076] [Examiner notes that the authorization/token module provides the token, the endpoint registration module 214 provides/directs the IHS to the address of the owner-specific onboarding service, therefore it provides the IHS with what it needs to authenticate and access the correct onboarding service. Also the module ties the token to authentication sources including the Active Directory, which ensures that the IHS receives credentials specific to the owner/enterprise]);
Andrews does not disclose: wherein presenting, by the IHS, the token to a firewall protecting the onboarding service; and in response to the presented token being recognized by the firewall, authorizing, by the firewall, onboarding communications by the IHS with the onboarding service in order to configure the IHS for the owner; wherein the token is trusted and used in the above steps only when presented from a specific originating IP address.
However, Jaiswal discloses: wherein presenting, by the IHS, the token to a firewall protecting the onboarding service; and in response to the presented token being recognized by the firewall, authorizing, by the firewall, onboarding communications by the IHS with the onboarding service in order to configure the IHS for the owner (“In 530, the firewall proxy returns an authorization token included in a distributed authentication cache cookie and a uniform resource locator (URL) for the web service to facilitate secure access to the web service from the client device. Subsequently, upon validating the received JWT token or the authorization token, the firewall proxy sets a site cookie for the domain with the user details and redirects the request to access the web service via the original URL” [0060-0061] [Examiner notes that the IHS presenting the token to the firewall corresponds to the client device communicating with the firewall proxy to gain access. The firewall proxy's act of returning an authorization token represents the successful receipt and recognition of the token presented by the IHS. The "URL for the web service" maps to the address of the onboarding service. The "validating the received JWT token or the authorization token" directly corresponds to "in response to the presented token being recognized by the firewall." The "redirects the request to access the web service via the original URL" aligns with authorizing onboarding communications by the IHS with the onboarding service. Essentially, after the IHS presents its credentials (the token), the firewall proxy acknowledges and responds to continue the secure handshake process. Once the token is validated, the firewall allows the IHS to proceed and communicate with the protected service (onboarding service)]);
wherein the token is trusted and used in the above steps only when presented from a specific originating IP address (“Referring to system 400 of FIG. 4, a proxy is configured for a browser or an operation system via a proxy auto-configuration (PAC) file on a client 410, whereby an IP address or a fully qualified domain name (FQDN) of an SPN is configured in the PAC file. In some embodiments, the PAC file is pushed onto a client. Subsequently, when the client 410 browses the Internet 450 by sending a URL request using a browser, the browser checks for the PAC file and forwards the URL request to the SPN 420 based on the IP address or the FQDN of the SPN included in the PAC file… If the authentication cookie is not present or is invalid, the user is redirected to the ACS 440. As an example, if the authentication cookie exists, the SPN 420 checks whether the current time has passed the time value of validity (or the expiration timestamp specified), and in the event that the time value of validity has not passed, the SPN 420 determines that the cookie is valid. After the ACS 440 confirms that the user has been authenticated, the user is redirected to the SPN 420 with a token. The SPN 420 then validates the token and sets a site cookie for that domain for the user. The SPN 420 applies security enforcement based on security policy rules that are configured by the administrator. In the event that no security policy rules are violated, the SPN 420 allows the URL request to go to the Internet 450” [0054] [Examiner notes that this text teaches that client requests are routed through an SPN using a specific IP configured in a proxy file. The SPN validates the user’s token after checking for validity (token only used when valid). The requests (and therefore token usage) are routed based on a specific IP address. Since all the requests are routed through the specified IP address and the token is only accepted upon validation at that node, the token is trusted and used only when presented from the specific IP originating IP address associated with the SPN. The claim recites “a specific originating IP address” without limiting the originating IP address to a client device. The specification likewise does not restrict the originating IP to the client, but instead broadly refers to restricting token use based on an originating IP address. In the disclosed system of the prior art, all requests are routed through the SPN and then the token is presented and validated at that node. As a result, from the perspective of token validation, the request effectively originates from the SPN’s IP address, since all authentication and token validation occurs at that node. Accordingly, the SPN’s IP address is being interpreted as the originating IP address from which the token was presented, satisfying the claimed limitations under BRI (no exclusion of intermediaries in specification)]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Andrews with the added structure of Jaiswal for the purpose of the service being able to facilitate/authenticate secure access to the web service from the client device (see Jaiswal, para 0060).
Claim 9 recites substantially the same limitation as claim 1, in the form of an IHS (Information Handling System) for implementing the corresponding method, therefore it is rejected under the same rationale. Examiner notes that the “one or more processors; and one or more memory devices coupled to the processors, the memory devices storing computer-readable instructions that, upon execution by the processors” limitation stated in the claim are read upon in Andrews (see para 0011-0013).
Claim 15 recites substantially the same limitation as claim 1, in the form of a system for
implementing the corresponding method, therefore it is rejected under the same rationale.
Regarding claim 8, a combination of Andrews-Jaiswal discloses the system of claim 1.
Andrews does not disclose: signing of the token by the rendezvous service, wherein the signed token includes an expiration and wherein the firewall rejects tokens with expired signatures.
However, Jaiswal discloses: signing of the token by the rendezvous service, wherein the signed token includes an expiration and wherein the firewall rejects tokens with expired signatures (“Referring to FIG. 2A, the end user/browser 610 sends an HTTP request, for example, www.myapp.com, to the Security Processing Node (SPN) 620 for authentication (step 1). In some embodiments, the SPN 620 is a firewall (FW) proxy. The SPN 620 then sends a request to an authentication cache service (ACS) 630 (step 2). The authentication cache service 630 checks whether the traffic is destined for the SPN 620. In response to a determination that the traffic is destined for the SPN 620, the SPN 620 decrypts the traffic and checks for a site cookie set by the SPN 620. In response to a determination that the SPN 620 does not find a valid cookie or the cookie is not valid for the application, the SPN 620 redirects the user to the ACS 630 for authentication through the browser with a signed JWT Token JWT-Tok1. As an example, the JWT Token includes the original URL, current timestamp, session start time, FW instance name, tenant-id, source-ip, and FW session-id. In the event that the end user/browser 610 has not been authenticated by the authentication cache service 630, the authentication cache service 630 sends a request to an SAML identity provider (IdP) 640 (step 3). The SAML IdP 640 authenticates the user (for example, the SAML IdP 640 requests username and password from the user or uses multi-factor authentication (MFA)) (step 4). After successful authentication of the user, the SAML IdP 640 sends an SAML assertion (for example, the SAML assertion includes user details and RelayState parameter) to the ACS 630 (step 5). In some embodiments, the RelayState parameter is an opaque identifier and stores state information at the ACS 630. The ACS 630 sends a signed and encrypted JWT Token JWT-Tok2 to the SPN 620 via a browser redirect and sets a site cookie ck_acs with a random key to the user information as a value for an ACS domain (step 6). As an example, the signed and encrypted JWT Token JWT-Tok2 includes a time value of validity (or an information expiration timestamp), user id, and original URL. The SPN 620 decrypts and validates the signed and encrypted JWT Token JWT-Tok2 from the ACS 630, sends another redirect to the original URL, and sets a site cookie for the domain with the user information (step 7). The SPN 620 validates the site cookie (e.g., verifies that the site cookie is not expired) and in the event that the site cookie is valid, the SPN allows the request to go to the web application/service 650 (e.g., www.myapp.com) (step 8)” [0046] [Examiner notes that in summary, this text explicitly shows that the SPN/firewall receive a signed JWT token and the token includes a time value of validity (expiration) which lets the firewall/SPN validate the token and only allows access if valid, effectively rejecting expired tokens. Examiner also notes that the ACS is seen as the rendezvous service here as they both provided the signed token to a client so it can authenticate to a service (both act as an intermediary in the exchange)]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Andrews with the added structure of Jaiswal for the purpose of making sure the token received to authorize connection is overall valid.
Claims 2-7, 10-14, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over US 2021/0136082 A1 to Andrews et al. (hereinafter, “Andrews”) in view of US 2022/0337590 A1 to Jaiswal et al. (hereinafter, “Jaiswal”) and in further view of Fido Device Onboard Specification 1.1. web page by FIDO Alliance from https://fidoalliance.org/specs/FDO/FIDO-Device-Onboard-PS-v1.1-20220419/FIDO-Device-Onboard-PS-v1.1-20220419.html#references dated April 19, 2022, hereinafter “Fido”.
Regarding claims 2, 10, and 16, a combination of Andrews-Jaiswal discloses the system of claims 1/9/15.
A combination of Andrews-Jaiswal do not disclose: wherein the onboarding system comprises a FIDO (Fast IDentity Online) Device Onboarding (FDO) system.
However, Fido discloses: wherein the onboarding system comprises a FIDO (Fast IDentity Online) Device Onboarding (FDO) system (“FIDO Device Onboard (FDO) protocols, version 1.1. FIDO Device Onboard is a device onboarding scheme from the FIDO Alliance, sometimes called "device provisioning"” [page 5]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Andrews-Jaiswal with the added structure of Fido for the purpose of a having FIDO (Fast IDentity Online) Device Onboarding (FDO) system (see Jaiswal, page 5).
Regarding claims 3, 11, and 17, a combination of Andrews-Jaiswal-Fido discloses the system of claims 2/10/16.
Fido further discloses: wherein the token is provided to the IHS by the rendezvous service as part of a TO1 protocol FDO exchange that is initiated upon the first powering of the IHS (“Transfer Ownership Protocol 1 (TO1) is an interaction between the Device ROE and the Rendezvous Server that points the Device ROE at its intended Owner Onboarding Service, which has recently completed Transfer Ownership Protocol 0. The TO1 Protocol is the mirror image of the TO0 Protocol, on the Device side. The TO1 Protocol starts with: A Device that has undergone the Device Initialize Protocol (DI) and thus has credentials (DeviceCredential) in its ROE identifying the particular Manufacturer Public Key that is in the Ownership Voucher. The Device is ready to power on. An Owner Onboarding Service and Rendezvous Server that have successfully completed Transfer Ownership Protocol 0: The Rendezvous Server has a relationship between the GUID stored in the device ROE and a rendezvous 'blob', as described above. The Owner Onboarding Service is waiting for a connection from the Device ROE on the network addresses referenced in the rendezvous 'blob.' If these conditions are not met, the Device will fail to complete the TO1 Protocol, and it will repeatedly try to complete the protocol with an interval of time between tries. The interval of time should be chosen with a random component to try to avoid congestion at the Rendezvous Server. After the TO1 Protocol completes successfully: The Device has rendezvous information sufficient to contact the Owner Onboarding Service directly. The Owner Onboarding Service is waiting for a connection from the Device ROE on the network addresses referenced in the rendezvous 'blob.' I.e., it is still waiting, since it does not participate in the TO1 Protocol” [Examiner notes that the text says after the TO1 completes successfully, the device has rendezvous information sufficient to contact the owner onboarding service directly. This "rendezvous information" is essentially the token or credentials that allows the IHS (device ROE) to authenticate and proceed with onboarding)] [page 19]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Andrews-Jaiswal with the added structure of Fido for the purpose of a having FIDO (Fast IDentity Online) Device Onboarding (FDO) system (see Jaiswal, page 5).
Regarding claims 4, 12, and 18, a combination of Andrews-Jaiswal-Fido discloses the system of claims 2/10/16.
Fido further discloses: wherein the token is presented by the IHS to the firewall protecting the onboarding service as part of a TO2 protocol FDO communication (“Transfer Ownership Protocol 2 (TO2) is an interaction between the Device ROE and the Owner Onboarding Service where the transfer of ownership to the new Owner actually happens. Before the TO2 Protocol begins: The Owner has received the Ownership Voucher, and run Transfer Ownership Protocol 0 to register its rendezvous 'blob' against the Device GUID. It is waiting for a connection from the Device ROE on the network addresses referenced in this 'blob.' The Device has undergone the Device Initialize Protocol (DI) and thus has credentials (DeviceCredential) in its ROE identifying the particular Manufacturer’s Public Key that is (hashed) in the Ownership Voucher. The Device has completed Transfer Ownership Protocol 1 (TO1), and thus has the rendezvous 'blob', containing the network address information needed to contact the Owner Onboarding Service directly. After the TO2 Protocol completes successfully: The Owner Onboarding Service has replaced all the device credentials with its own, except for the Device’ attestation key. The Device ROE has allocated a new secret and given the Owner a HMAC to use in a new Ownership Voucher, which can be used for resale. See § 6 Resale Protocol. The Owner Onboarding Service has transferred new credentials to the Device ROE in the form of key-value pairs. These credentials include enough information for the Device ROE to invoke the correct Management Agent and allow it to connect to the Owner’s Management service. The set of parameters is given in the following messages, although the OwnerServiceInfo is an extensible mechanism… The Owner Onboarding Service has transferred these credentials to the Owner’s Manager, which is now ready to receive a connection from the Device. The Device ROE has received these credentials, and has invoked the Management Agent and given it access to these credentials. The Management Agent has received these credentials is ready to connect to the Owner’s Manager. In a given Device, there may be a distinction between: the Device ROE and the Management Agent; and between the Owner Onboarding Service and the Owner’s Manager: The Device ROE performs the FIDO Device Onboard protocols and manipulates and stores FIDO Device Onboard credentials. The Device ROE is likely to store other credentials and perform other services (e.g., cryptographic services) for the device. The Device itself runs its basic functions. Amongst these is the Management Agent, a service process that connects it to its remote Manager. This software is often called an “agent”, or “client.” We intend that this software can be a pre-existing agent for the Management Service chosen by the Owner, which may also operate on devices that do not use FIDO Device Onboard. The Owner Onboarding Service is a body of software that is dedicated specifically to run the FIDO Device Onboard Protocol on behalf of the Manager. For example, this code might have its own IP addresses, so that the eventual Manager IP addresses (which may be well known) are hidden from prying eyes. The Owner Manager is an Internet-resident service that provides management services for the Owner on an ongoing basis. FIDO Device Onboard is designed to work with pre-existing management services for IoT devices. After Transfer Ownership Protocol 2, the FIDO Device Onboard specific software is no longer needed until and unless a new ownership transfer is intended, such as when the device is re-sold or if trust needs to be established anew. FIDO Device Onboard client software adjusts itself so that it does not attempt any new protocols after the TO2 Protocol. Implementation-specific configuration can be used to re-enable ownership transfer (e.g., a CLI command)” [pages 20-21] [Examiner notes that the owner's manager is the protected endpoint that only allows connections from devices presenting valid credentials. The device ROE acts as the client presenting the "token" (credentials received during TO2) and access is only granted if the credentials are valid, just like a firewall only allows traffic that meets its rules]).
It would have been obvious to one of ordinary skill in the art before the priority date to modify Andrews-Jaiswal with the added structure of Fido for the purpose of a having FIDO (Fast IDentity Online) Device Onboarding (FDO) system (see Jaiswal, page 5).
Regarding claims 5, 13, and 19, a combination of Andrews-Jaiswal-Fido discloses the system of claims 2/10/16.
Fido further discloses: wherein the token is provided by the owner to the rendezvous service during a TO0 protocol FDO communication (“Transfer Ownership Protocol 0 (TO0) serves to connect the Owner Onboarding Service with the Rendezvous Server. In this protocol, the Owner Onboarding Service indicates its intention and proves it is capable of taking control of a specific Device, based on the Device’s current GUID. Transfer Ownership Protocol 0 starts with: A presumed Device that has undergone the Device Initialize Protocol (DI) and thus has credentials in its ROE (DeviceCredential) identifying the Manufacturer public key that is in the Ownership Voucher. The Device is not a party to this protocol, and may be powered off, in a box, or in transit when the protocol is run. The Owner Onboarding Service has access to the following: An Ownership Voucher, whose last Public key belongs to the Owner, and the GUID of the device, which is also authorized by the Ownership Voucher. The private key that is associated with the Owner’s public key in the Ownership Voucher. An IP address from which to operate. This IP address need bear no relationship to the service addresses that are used by the Owner. The Owner may take steps to hide its address, such as allocating it dynamically (e.g., using DHCP) or using an IPv6 privacy address. The motivation for hiding this IP address is to maintain the privacy of the Owner from the Rendezvous Server or from anyone monitoring network traffic in the vicinity of the Rendezvous Server. This can never be done for sure; we think of it as raising the bar on an attacker. The Rendezvous Server has some way to trust at least one key in the Ownership Voucher. For example, the Manufacturer has selected the Rendezvous Server, then the Rendezvous Server might be aware of the Manufacturer’s public key used in the Ownership Voucher. Transfer Ownership Protocol 0 ends with: The Rendezvous Server has an entry in a table that associates, for a specified interval of time, the Device GUID with the Owner Onboarding Service’s rendezvous 'blob.' The blob contains an array of {DNS name, IP address, port, protocol}. The Owner Onboarding Service is waiting for a connection from the Device ROE at this DNS name and/or IP address for this same amount of time. If the Device ROE appears within the set time interval, it can complete Transfer Ownership Protocol 1 (TO1). Otherwise, the Rendezvous Server forgets the relationship between GUID and Rendezvous 'blob.' A subsequent TO1 from the Device ROE will return an error, and the Device will not be able to onboard. The Owner Onboarding Service can extend the time interval by running Transfer Ownership Protocol 0 again. It may do so from a different IP address. In the case of a device being connected to a cloud service, the Owner Onboarding Service typically would repeatedly perform the TO0 Protocol until all devices known to it successfully complete the TO2 Protocol. In the case of a Device being connected using an application program implementation of the Owner Onboarding Service, the Owner might arrange to turn on the Owner Onboarding Service shortly before turning on the device, to expedite the protocol. The Rendezvous Server is only trusted to faithfully remember the GUID to Owner blob mapping. The other checks performed protect the server from DoS attacks, but are not intended to imply a greater trust in the server. In particular, the Rendezvous Server is not trusted to authorize device transfer of ownership. Furthermore, the Rendezvous Server never directly learns the result of the device transfer of ownership” [pages 18-19] [Examiner notes that the token is interpreted as the credentials derives from the ownership voucher and owner's key that the owner provides to the rendezvous service]).
It would have been obvious to one of ordinary skill in the art before the priority date to modify Andrews-Jaiswal with the added structure of Fido for the purpose of a having FIDO (Fast IDentity Online) Device Onboarding (FDO) system (see Jaiswal, page 5).
Regarding claims 6, 14, and 20, a combination of Andrews-Jaiswal-Fido discloses the system of claims 2/10/16.
Andrews further discloses: a certificate authority that must be utilized in connecting with the firewall protecting the onboarding service (“In certain embodiments, the multilevel authentication system may utilize separate certificates for each level of authentication, and may also support authentication of the integrity of the certificates in use at all of these levels during a workspace session through a calculation of a single hash value. In the three-level authentication system illustrated in FIG. 4, an IHS certificate 415 may be used to authenticate the identity of the IHS 430 and the integrity of certain hardware of IHS 430. In some embodiments, the IHS certificate 415 may be generated as part of a trusted provisioning process conducted as part of the manufacture of IHS 430. In such embodiments, the IHS certificate 415 may be digitally signed using a certificate authority associated with the manufacturer and/or seller of the IHS 430. As illustrated, the IHS certificate 415 may include various information used to authenticate the IHS 430, and in particular used to authenticate the integrity of certain hardware of IHS 430. In support of identifying IHS 430, the IHS certificate 415 may specify a unique identifier associated with the IHS 430, such as a service tag number, serial number, machine address or other unique identifier assigned only to IHS 430” [0121] [Examiner notes that the IHS certificate 415 functions as the token as it is a digital object used to prove identity and establish trust when initiating secure communications. This shows that the token includes/derives from CA signatures. The firewall protecting the onboarding service would rely on this certificate to validate the connecting IHS. The certificate (CA-backed token) enables the IHS to prove its identity before the fire wall grants access]).
Regarding claims 7, a combination of Andrews-Jaiswal-Fido discloses the system of claim 6.
Andrews further discloses: rejecting, by the IHS, the onboarding session with the onboarding service when the firewall does not utilize a connection that is secured with credentials that are validated by the certificate authority (“Web services 306 that may be used in support of workspaces may further include resource provisioning services 312 for configuring an IHS or workspace with secrets/credentials necessary to access specific resources (e.g., credentials for use of VPNs, networks, data storage repositories, workspace encryption, workspace attestation, and workspace-to-device anchoring). In some cases, resource provisioning services 312 may include secrets provisioned as part of a trusted assembly process of IHS 300B and, in some instances, associated with a unique identifier 348 of the IHS 300B. In certain embodiments, resource provisioning service 312 may support multi-level authentication of workspaces 331A-N operating on IHS 300B. For instance, resource provisioning service 312 may provide IHS 300B with certificates and other cryptographic information for use in authenticating the hardware in use by IHS 300B, the configuration of IHS 300B for use of workspaces and the workspaces sessions deployed for operation by IHS 300B” [0075] [Examiner notes that the IHS is equipped to verify the credentials and if they fails, it can reject the session. These credentials are used to establish secure connections (through a firewall for example). Also, the certificates are the CA signed credentials that the IHS uses to confirm the authenticity of the connection. If the firewall connection doesn't match this CA validation, the IHS will reject it since the resource provisioning service 312 equips the IHS with CA signed certificates and cryptographic secrets]).
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should
be directed to SARON MATTHEWOS WORKU whose telephone number is (703)756-1761. The
examiner can normally be reached Monday - Friday, 9:30am - 6:30pm.
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, Linglan Edwards can be reached on 571-270-5440. 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.
/SARON MATTHEWOS WORKU/Examiner, Art Unit 2408
/LINGLAN EDWARDS/Supervisory Patent Examiner, Art Unit 2408