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 .
This action is responsive to communication received on 01/24/2024. The applicant has submitted 18 claims for examination, all claims are currently pending.
The Examiner recommends filing a written authorization for Internet communication in response to the present action. Doing so permits the USPTO to communicate with Applicant using Internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
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 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.
Claims 1, 16, 17 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta US 2020/0059881, and further in view of Halstead US 2023/0185929.
Regarding claims 1 and 18, Gupta teaches a method and non-transitory CRM for a method of operating storage equipment, the method registering the storage equipment as an untrusted client at a data center through first connectivity between a connectivity client embedded within the storage equipment and the data center, the connectivity client obtaining a set of temporary credentials while registering(edge device that provides storage and processing of sensors and other IOT devices initiate enrollment to the cloud network sending device credentials(ie. bootstrap cert) and receiving a temporary authorization(untrusted) for further establishment of permanent authentication(trusted) in a enrolled status, ¶s15,23 )
[0015] As discussed above, traditional cloud computing provides a shared pool of configurable computing resources that can be provisioned and released for those nodes having access to those resources. But traditional cloud computing relies upon large amounts of data being transferred from and to the accessing nodes. This can consume time and networking resources unnecessarily. Thus, edge computing has been introduced as a way to reduce the flow of traffic from devices on the edge of the cloud (e.g., industrial networks that incorporate internet of things (IoT) devices) and provide near real-time local data analysis, while transferring only the data that needs to be transferred to the cloud resources. In one example of a typical edge-computing scenario, IoT devices transfer data gathered by those devices to a local, edge-computing device that includes compute, storage, and network resources in a small form factor. Data is processed at the edge, responded to appropriately, and only what is needed to be transferred to the cloud-based resources is transferred.
[0023] Phase 2 is an association, authentication, and authorization phase (AAA) 320 that uses the bootstrapping certificate provided to the device in Phase 1 to establish a secure connection with AAA server 240. During this phase, device specific parameters such as manufacturer user ID, OEM user ID, device serial number, and the like, can be used to authenticate the device. If the device is authenticated, then a temporary authorization token can be issued to the device for further authentication.
establishing second connectivity between the connectivity client and the data center based on the set of temporary credentials, the second connectivity providing stronger security than the first connectivity(in 2nd phase the secure connection is established using temp credentials to obtain long term certificate and create a trusted connectivity , ¶24)
[0024] Phase 3 is an enrollment phase 330 that uses the temporary authorization token to establish a secure connection with enrollment EST (E-EST) server 250. E-EST server will perform final authorization tasks and issue a long-term operation certificate that will allow the device to access services in operations trust area 210. As illustrated, there can be some devices that are securely manufactured and configured that can skip Phase 1 and Phase 2, and therefore interact directly with Phase 3 to gain access to the operations trust area. Finally, after completing the enrollment phase, devices can enter operations phase 340, accessing cloud services 150 served by operations trust area 210.
and after establishing the second connectivity between the connectivity client and the data center, providing trusted communications between the connectivity client and the data center through the second connectivity to manage the storage equipment(after enrollment, edge device gains operations access where it can be managed from the clouds, i.e. operations trust area, ¶14,33)
[0014] Embodiments of the present invention provide a mechanism for secure enrollment of devices with a cloud platform. This serves as a foundation for securing devices, such as edge computing and internet-of-things gateways, that can be provisioned and managed from the cloud. A public key infrastructure (PKI) mechanism is provided for enrollment that is split into three phases. The first and second phases of the secure enrollment process authenticate the device and ensure that the device is within agreed to manufacturing limits for the device manufacturer. The third phase of the secure enrollment process provides a long-term operating certification to the device for cloud resource access.
[0033] FIG. 6 is a simplified timing diagram illustrating details of enrollment EST phase 330 in accord with one embodiment of the present invention. The figure illustrates communication between the client device (e.g., network node 110 or edge services node 120) and an enrollment EST server (e.g., E-EST server 250) during which the client device connects to the E-EST server and obtains an operations CA certificate for use in accessing cloud services 150 in operations area 210. Initially, the client device connects with the E-EST server using a secure communication protocol such as TLS/SSL or HTTPS (610). The communication can be secured using the enrollment CA certificate programmed into the device during manufacture or the bootstrap certificate received in Phase 1. Identification of the appropriate E-EST server can be provided during Phase 2 of the enrollment process (e.g., as part of the e-token transfer) or the identification can be programmed into the device during manufacture.
Gupta teaches a device enrollment process that comprises a two phase untrusted connection and trusted connection phase but does not specifically teach triggering such a process in response to a startup command. Halstead in the same field of endeavor as the invention teaches a system and method virtual device enrollment. Halstead teaches performing an enrollment process in response to a startup command.
[0042] Executing the enrollment agent 206 as part of the startup of the virtual device 147 can ensure that the virtual device 147 is enrolled for management by the management service 120. The enrollment agent 206 of the virtual device 147 can require a privileged status generally associated with privileged user accounts. For example, the enrollment agent 206 of the virtual device 147 can require a privileged status to access and decrypt the encrypted configuration file 212 to retrieve the enrollment credentials 221. However, the user credentials 215 provided to the virtual machine operating system 203 at startup can be associated with an unprivileged or non-administrative user account.
It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to modify Gupta with initiation of a device enrollment process up startup of a device as taught by Halstead. The reason for this modification would be to automate the enrollment of a device providing a improvement over manual enrollment processes.
Regarding claim 16, Gupta teaches storage equipment, comprising: a set of storage devices constructed and arranged to store data; and storage equipment circuitry coupled with the set of storage devices, the storage equipment circuitry being constructed and arranged to provide a connectivity client and perform a method of(IOT edge devices serving to store and process data from other IOT devices/sensors, ¶15)
[0015] As discussed above, traditional cloud computing provides a shared pool of configurable computing resources that can be provisioned and released for those nodes having access to those resources. But traditional cloud computing relies upon large amounts of data being transferred from and to the accessing nodes. This can consume time and networking resources unnecessarily. Thus, edge computing has been introduced as a way to reduce the flow of traffic from devices on the edge of the cloud (e.g., industrial networks that incorporate internet of things (IoT) devices) and provide near real-time local data analysis, while transferring only the data that needs to be transferred to the cloud resources. In one example of a typical edge-computing scenario, IoT devices transfer data gathered by those devices to a local, edge-computing device that includes compute, storage, and network resources in a small form factor. Data is processed at the edge, responded to appropriately, and only what is needed to be transferred to the cloud-based resources is transferred.
registering the storage equipment as an untrusted client at a data center through first connectivity between a connectivity client embedded within the storage equipment and the data center, the connectivity client obtaining a set of temporary credentials while registering(edge device that provide storage and processing of sensors and other IOT devices initiate enrollment to the cloud network sending device credentials and receiving a temporary authorization(untrusted) for further establishment of permanent authentication(trusted) in a enrolled status, ¶s15,23 )
[0015] As discussed above, traditional cloud computing provides a shared pool of configurable computing resources that can be provisioned and released for those nodes having access to those resources. But traditional cloud computing relies upon large amounts of data being transferred from and to the accessing nodes. This can consume time and networking resources unnecessarily. Thus, edge computing has been introduced as a way to reduce the flow of traffic from devices on the edge of the cloud (e.g., industrial networks that incorporate internet of things (IoT) devices) and provide near real-time local data analysis, while transferring only the data that needs to be transferred to the cloud resources. In one example of a typical edge-computing scenario, IoT devices transfer data gathered by those devices to a local, edge-computing device that includes compute, storage, and network resources in a small form factor. Data is processed at the edge, responded to appropriately, and only what is needed to be transferred to the cloud-based resources is transferred.
[0023] Phase 2 is an association, authentication, and authorization phase (AAA) 320 that uses the bootstrapping certificate provided to the device in Phase 1 to establish a secure connection with AAA server 240. During this phase, device specific parameters such as manufacturer user ID, OEM user ID, device serial number, and the like, can be used to authenticate the device. If the device is authenticated, then a temporary authorization token can be issued to the device for further authentication.
establishing second connectivity between the connectivity client and the data center based on the set of temporary credentials, the second connectivity providing stronger security than the first connectivity(in phase the secure connection is established using temp credentials to obtain long term certificate and create a trusted connectivity , ¶24)
[0024] Phase 3 is an enrollment phase 330 that uses the temporary authorization token to establish a secure connection with enrollment EST (E-EST) server 250. E-EST server will perform final authorization tasks and issue a long-term operation certificate that will allow the device to access services in operations trust area 210. As illustrated, there can be some devices that are securely manufactured and configured that can skip Phase 1 and Phase 2, and therefore interact directly with Phase 3 to gain access to the operations trust area. Finally, after completing the enrollment phase, devices can enter operations phase 340, accessing cloud services 150 served by operations trust area 210.
and after establishing the second connectivity between the connectivity client and the data center, providing trusted communications between the connectivity client and the data center through the second connectivity to manage the storage equipment(after enrollment edge device gains operations access where it can be managed from the clouds, i.e. operations trust area, ¶14,33)
[0014] Embodiments of the present invention provide a mechanism for secure enrollment of devices with a cloud platform. This serves as a foundation for securing devices, such as edge computing and internet-of-things gateways, that can be provisioned and managed from the cloud. A public key infrastructure (PKI) mechanism is provided for enrollment that is split into three phases. The first and second phases of the secure enrollment process authenticate the device and ensure that the device is within agreed to manufacturing limits for the device manufacturer. The third phase of the secure enrollment process provides a long-term operating certification to the device for cloud resource access.
[0033] FIG. 6 is a simplified timing diagram illustrating details of enrollment EST phase 330 in accord with one embodiment of the present invention. The figure illustrates communication between the client device (e.g., network node 110 or edge services node 120) and an enrollment EST server (e.g., E-EST server 250) during which the client device connects to the E-EST server and obtains an operations CA certificate for use in accessing cloud services 150 in operations area 210. Initially, the client device connects with the E-EST server using a secure communication protocol such as TLS/SSL or HTTPS (610). The communication can be secured using the enrollment CA certificate programmed into the device during manufacture or the bootstrap certificate received in Phase 1. Identification of the appropriate E-EST server can be provided during Phase 2 of the enrollment process (e.g., as part of the e-token transfer) or the identification can be programmed into the device during manufacture.
Gupta teaches a device enrollment process that comprises a two phase untrusted connection and trusted connection phase but does not specifically teaches triggering such a process in response to a startup command. Halstead in the same field of endeavor as the invention teaches a system and method virtual device enrollment. Halstead teaches performing an enrollment process in response to a startup command.
[0042] Executing the enrollment agent 206 as part of the startup of the virtual device 147 can ensure that the virtual device 147 is enrolled for management by the management service 120. The enrollment agent 206 of the virtual device 147 can require a privileged status generally associated with privileged user accounts. For example, the enrollment agent 206 of the virtual device 147 can require a privileged status to access and decrypt the encrypted configuration file 212 to retrieve the enrollment credentials 221. However, the user credentials 215 provided to the virtual machine operating system 203 at startup can be associated with an unprivileged or non-administrative user account.
It would have been obvious to a person of ordinary skill in the art, before the effective filing date of the claimed invention to modify Gupta with initiation of a device enrollment process up startup of a device as taught by Halstead. The reason for this modification would be to automate the enrollment of a device providing a improvement over manual enrollment processes.
Regarding claim 17, Gupta teaches: a set of management servers(E-EST server) constructed and arranged to manage storage equipment; and data center circuitry coupled with the set of management servers, the data center circuitry being constructed and arranged to perform a method of:
[0020] FIG. 2 is a simplified block diagram illustrating an example of a certificate authority trust infrastructure suitable for embodiments of the present invention. Each certificate authority controls trusted access to a set of servers and services in the cloud. Embodiments of the present invention control enrollment to cloud services by having two separate trust areas—enrollment and operations—with each trust area governed by a separate certificate authority. Cloud services 150, as illustrated in FIG. 1, are in operations trust area 210, to which secure access is controlled by operations CA 220. An enrollment CA 270 controls secure access to enrollment trust area 260. As illustrated, enrollment trust area 260 includes a Bootstrapping Enrollment over Secure Transport (EST) server 230, an Association, Authentication, an Authorization server 240, and an Enrollment EST server 250. The functions of each of these enrollment trust area servers will be discussed in greater detail below.
registering the storage equipment as an untrusted client at a data center through first connectivity between a connectivity client embedded within the storage equipment and the data center, the connectivity client obtaining a set of temporary credentials while registering(edge device that provide storage and processing of sensors and other IOT devices initiate enrollment to the cloud network sending device credentials and receiving a temporary authorization(untrusted) for further establishment of permanent authentication(trusted) in a enrolled status, ¶s15,23 )
[0015] As discussed above, traditional cloud computing provides a shared pool of configurable computing resources that can be provisioned and released for those nodes having access to those resources. But traditional cloud computing relies upon large amounts of data being transferred from and to the accessing nodes. This can consume time and networking resources unnecessarily. Thus, edge computing has been introduced as a way to reduce the flow of traffic from devices on the edge of the cloud (e.g., industrial networks that incorporate internet of things (IoT) devices) and provide near real-time local data analysis, while transferring only the data that needs to be transferred to the cloud resources. In one example of a typical edge-computing scenario, IoT devices transfer data gathered by those devices to a local, edge-computing device that includes compute, storage, and network resources in a small form factor. Data is processed at the edge, responded to appropriately, and only what is needed to be transferred to the cloud-based resources is transferred.
[0023] Phase 2 is an association, authentication, and authorization phase (AAA) 320 that uses the bootstrapping certificate provided to the device in Phase 1 to establish a secure connection with AAA server 240. During this phase, device specific parameters such as manufacturer user ID, OEM user ID, device serial number, and the like, can be used to authenticate the device. If the device is authenticated, then a temporary authorization token can be issued to the device for further authentication.
establishing second connectivity between the connectivity client and the data center based on the set of temporary credentials, the second connectivity providing stronger security than the first connectivity(in phase the secure connection is established using temp credentials to obtain long term certificate and create a trusted connectivity , ¶24)
[0024] Phase 3 is an enrollment phase 330 that uses the temporary authorization token to establish a secure connection with enrollment EST (E-EST) server 250. E-EST server will perform final authorization tasks and issue a long-term operation certificate that will allow the device to access services in operations trust area 210. As illustrated, there can be some devices that are securely manufactured and configured that can skip Phase 1 and Phase 2, and therefore interact directly with Phase 3 to gain access to the operations trust area. Finally, after completing the enrollment phase, devices can enter operations phase 340, accessing cloud services 150 served by operations trust area 210.
and after establishing the second connectivity between the connectivity client and the data center, providing trusted communications between the connectivity client and the data center through the second connectivity to manage the storage equipment(after enrollment edge device gains operations access where it can be managed from the clouds, i.e. operations trust area, ¶14,33)
[0014] Embodiments of the present invention provide a mechanism for secure enrollment of devices with a cloud platform. This serves as a foundation for securing devices, such as edge computing and internet-of-things gateways, that can be provisioned and managed from the cloud. A public key infrastructure (PKI) mechanism is provided for enrollment that is split into three phases. The first and second phases of the secure enrollment process authenticate the device and ensure that the device is within agreed to manufacturing limits for the device manufacturer. The third phase of the secure enrollment process provides a long-term operating certification to the device for cloud resource access.
[0033] FIG. 6 is a simplified timing diagram illustrating details of enrollment EST phase 330 in accord with one embodiment of the present invention. The figure illustrates communication between the client device (e.g., network node 110 or edge services node 120) and an enrollment EST server (e.g., E-EST server 250) during which the client device connects to the E-EST server and obtains an operations CA certificate for use in accessing cloud services 150 in operations area 210. Initially, the client device connects with the E-EST server using a secure communication protocol such as TLS/SSL or HTTPS (610). The communication can be secured using the enrollment CA certificate programmed into the device during manufacture or the bootstrap certificate received in Phase 1. Identification of the appropriate E-EST server can be provided during Phase 2 of the enrollment process (e.g., as part of the e-token transfer) or the identification can be programmed into the device during manufacture.
Gupta teaches a device enrollment process that comprises a two phase untrusted connection and trusted connection phase but does not specifically teaches triggering such a process in response to a startup command. Halstead in the same field of endeavor as the invention teaches a system and method virtual device enrollment. Halstead teaches performing an enrollment process in response to a startup command.
[0042] Executing the enrollment agent 206 as part of the startup of the virtual device 147 can ensure that the virtual device 147 is enrolled for management by the management service 120. The enrollment agent 206 of the virtual device 147 can require a privileged status generally associated with privileged user accounts. For example, the enrollment agent 206 of the virtual device 147 can require a privileged status to access and decrypt the encrypted configuration file 212 to retrieve the enrollment credentials 221. However, the user credentials 215 provided to the virtual machine operating system 203 at startup can be associated with an unprivileged or non-administrative user account.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Gupta with initiation of a device enrollment process up startup of a device as taught by Halstead. The reason for this modification would be to automate the enrollment of a device providing a improvement over manual enrollment processes.
Claims 2-5 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta/Halstead as applied to claim 1 above, and further in view of Woodage 2024/0195641.
Regarding claim 2, Gupta teaches wherein the data center includes a storefront server; wherein the first connectivity includes a first connection between the connectivity client and the storefront server(client authenticates with AAA server and received temporary e-token/certificate)
[0031] Once the client device is authenticated, the AAA server can provide the client device with a temporary enrollment e-token or certificate (550), which is stored by the client device for use in the next phase (560). As with the certificate provided in Phase 1, the Phase 2 enrollment e-token is temporary to avoid issues associated with hijacking and decrypting the enrollment e-token to gain access to subsequent phases of the enrollment process. The AAA server can maintain a mapping table that contains all active client device IDs to e-token mappings, along with expiration times for the e-tokens. The E-EST server in Phase 3 can use the table to authenticate devices in that Phase.
and wherein registering the storage equipment as an untrusted client at the data center through the first connectivity includes: delivering a temporary certificate from the storefront server to the connectivity client through the first connection between the connectivity client and the storefront server of the data center(temporary enrollment cert is received by client for use in third long term phase of authentication(i.e. operations ) , ¶31).
[0031] Once the client device is authenticated, the AAA server can provide the client device with a temporary enrollment e-token or certificate (550), which is stored by the client device for use in the next phase (560). As with the certificate provided in Phase 1, the Phase 2 enrollment e-token is temporary to avoid issues associated with hijacking and decrypting the enrollment e-token to gain access to subsequent phases of the enrollment process. The AAA server can maintain a mapping table that contains all active client device IDs to e-token mappings, along with expiration times for the e-tokens. The E-EST server in Phase 3 can use the table to authenticate devices in that Phase.
Gupta teaches delivering a temporary certificate but is silent regarding also including a temporary identifier. Woodage in the same field of endeavor teaches a system for device enrollment using public key infrastructure. Woodage teaches delivering both a temporary certificate and temporary identifier( temporary public key associated with device identifier, included in temp certificate, ¶175)
[0175] Once all checks are completed, the KMS 120 signs a temporary enrolment device certificate 1042 (labelled “TE_Dev_Cert”). The temporary enrolment device certificate 1042 includes: the device identifier as the Subject Name, EPK as the public key, and a validity period. The TE_Dev_Cert 1042 is signed by secret key associated with the temporary enrolment issuing certificate 1040 (TE_OEM_IC).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Gupta/Halstead with incorporation of a device id related temporary pubic key along with the temporary enrollment certification The reason for this modification would be to implement a more secure method of device enrollment ensuring that only valid device IDs can be successfully enroll and gain operational access.
Regarding claim 3, Gupta teaches wherein the data center further includes a set of management servers that is different from the storefront server(enrollment server(e-est) cloud services servers in operations trust network, ¶35) and wherein establishing the second connectivity includes: creating, as at least part of the second connectivity, a second connection between the connectivity client and the set of management servers of the data center, the second connection being different from the first connection(second connection using permanent operations certificate for secure connection access operations services, ¶35)
[0035] After receiving the enrollment e-token information along with any other information required by the E-EST server, the E-EST server authenticates the client device (630). If the information provided by the client device does not clear authentication (e.g., the enrollment e-token has expired), then the E-EST server will not provide a certificate to gain access to the operations services. If the information does clear authentication, then the E-EST server can communicate with the operations CA to acquire a long-term operations security certificate (640) which is then provided to the client device (650). The client device the stores the operations security certificate and can generate device-specific keys related to the operations CA for access to operations services 150 (660).
Regarding claim 4, Gupta teaches wherein creating the second connection between the connectivity client and the set of management servers of the data center includes: based on the set of temporary credentials obtained by the connectivity client while registering, performing handshaking and validation operations between the connectivity client and the set of management servers to form a trusted connection as the second connection(connections setup between devices and servers setup TLS connection session, TLS connection implies a handshake process to setup of secure communication, ¶18).
[0018] To restrict access to cloud services resources, device authentication mechanisms are used. One method to authenticate devices is using certificate-based authentication. A digital certificate (also known as a public key certificate or an identity certificate) is used to identify the device before granting access to a resource, network, application, and the like. A secure sockets layer/transport layer security (SSL/TLS) certificate is a type of digital certificate that binds ownership details of a server to cryptographic keys. The keys are used in SSL/TLS protocol communications to activate a secure session between a client and the server hosting the certificate. In order for a client to trust a SSL/TLS certificate, and establish a SSL/TLS session without security warnings, the SSL/TLS certificate should include the domain name of the server using it, and be issued by a trusted certificate authority (CA). The digital certificate is issued by a Certificate Authority (CA)—a trusted network node that is pre-authorized to issue SSL/TLS certificates.
Regarding claim 5, Gupta teaches wherein providing the trusted communications between the connectivity client and the data center includes: deploying storage equipment software from the set of management servers to the storage equipment through the trusted connection and the connectivity client, the storage equipment software being constructed and arranged to install and operate on the storage equipment to process input/output (I/O) requests on behalf of a set of host computers(client devices are network/edge nodes that provisioned to provide functions such as collecting and analyzing sensor data at the edge of a network, ¶17).
[0017] Network nodes 110 can be, for example, internet of things (IoT) type devices that can provide distributed sensor and other apparatus functionality. These devices can be configured to gather data related to their environment. Either network nodes 110 or edge services node 120 can provide computation resources to analyze and respond to data gathered by network nodes 110 closer to where the data is generated than cloud services 150. This allows for quicker responses to such data, which can be especially important for environments gathering latency sensitive information (e.g., financial services, manufacturing, and medical). This also allows for locally filtering data to only provide to cloud services 150 data that is important or necessary. This can arise, for example, in an environment where large amounts of data is produced, but most of that data is inconsequential. In addition to utilizing cloud services 150 for centralized compute, storage, and other network applications, edge computing nodes such as network nodes 110 and edge services node 120 can also utilize the cloud services for firmware and software installation, updates, and configuration.
Regarding claim 10, Gupta teaches wherein the storage equipment is disposed at a storage equipment location(edge network nodes provide storage and processing of data from sensors, ¶17)
wherein the data center resides at a set of remote locations that is different from the storage equipment location(cloud services provide management over a wide area network to the edge network, ¶17 fig 1)
wherein the connections extend over a public network that connects the storage equipment location with the set of remote locations(cloud services provide management over a wide area network to the edge network, ¶17 fig 1)
and wherein providing the trusted communications between the connectivity client and the data center includes: electronically managing the storage equipment from the data center through at least some of the connections that extend over the public network(edge network device are managed and provisioned from the cloud network, ¶s14,17).
[0014] Embodiments of the present invention provide a mechanism for secure enrollment of devices with a cloud platform. This serves as a foundation for securing devices, such as edge computing and internet-of-things gateways, that can be provisioned and managed from the cloud. A public key infrastructure (PKI) mechanism is provided for enrollment that is split into three phases. The first and second phases of the secure enrollment process authenticate the device and ensure that the device is within agreed to manufacturing limits for the device manufacturer. The third phase of the secure enrollment process provides a long-term operating certification to the device for cloud resource access.
[0017] Network nodes 110 can be, for example, internet of things (IoT) type devices that can provide distributed sensor and other apparatus functionality. These devices can be configured to gather data related to their environment. Either network nodes 110 or edge services node 120 can provide computation resources to analyze and respond to data gathered by network nodes 110 closer to where the data is generated than cloud services 150. This allows for quicker responses to such data, which can be especially important for environments gathering latency sensitive information (e.g., financial services, manufacturing, and medical). This also allows for locally filtering data to only provide to cloud services 150 data that is important or necessary. This can arise, for example, in an environment where large amounts of data is produced, but most of that data is inconsequential. In addition to utilizing cloud services 150 for centralized compute, storage, and other network applications, edge computing nodes such as network nodes 110 and edge services node 120 can also utilize the cloud services for firmware and software installation, updates, and configuration.
Claim 6-9 and 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta/Halstead/Woodage as applied to claim 4 above, and further in view of Sundararajan US 2024/0223579.
Regarding claim 6, Gupta/Halstead/Woodage teach deploying storage and processing resources to edge nodes but does not specifically teach wherein providing the trusted communications between the connectivity client and the data center includes: providing a set of user commands from the set of management servers to the storage equipment through the trusted connection and the connectivity client, the set of user commands being constructed and arranged to create a set of storage objects which hold host data on the storage equipment. Sundararajan in the same field of endeavor as the invention teaches a system for management of container based distributed storage systems. Sundararajan teaches wherein providing the trusted communications between the connectivity client and the data center includes: providing a set of user commands from the set of management servers to the storage equipment through the trusted connection and the connectivity client, the set of user commands being constructed and arranged to create a set of storage objects which hold host data on the storage equipment( file server commands, REST API commands provide for managing storage systems where storage systems are provisioned as manage storage objects, ¶s121,132)
[0121] Although not explicitly depicted in FIG. 3A, readers will appreciate that a vast amount of additional hardware components and additional software components may be necessary to facilitate the delivery of cloud services to the storage system 306 and users of the storage system 306. For example, the storage system 306 may be coupled to (or even include) a cloud storage gateway. Such a cloud storage gateway may be embodied, for example, as hardware-based or software-based appliance that is located on premise with the storage system 306. Such a cloud storage gateway may operate as a bridge between local applications that are executing on the storage system 306 and remote, cloud-based storage that is utilized by the storage system 306. Through the use of a cloud storage gateway, organizations may move primary iSCSI or NAS to the cloud services provider 302, thereby enabling the organization to save space on their on-premises storage systems. Such a cloud storage gateway may be configured to emulate a disk array, a block-based device, a file server, or other storage system that can translate the SCSI commands, file server commands, or other appropriate command into REST-space protocols that facilitate communications with the cloud services provider 302.
[0132] The example storage system 306 depicted in FIG. 3B may implement a variety of storage architectures. For example, storage systems in accordance with some embodiments of the present disclosure may utilize block storage where data is stored in blocks, and each block essentially acts as an individual hard drive. Storage systems in accordance with some embodiments of the present disclosure may utilize object storage, where data is managed as objects. Each object may include the data itself, a variable amount of metadata, and a globally unique identifier, where object storage can be implemented at multiple levels (e.g., device level, system level, interface level). Storage systems in accordance with some embodiments of the present disclosure utilize file storage in which data is stored in a hierarchical structure. Such data may be saved in files and folders, and presented to both the system storing it and the system retrieving it in the same format.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Gupta/Halstead/Woodage with software-defined storage. The reason for this modification would be to provide scalable storage system deployment and management.
Regarding claim 7, Gupta/Halstead/Woodage does not teach wherein providing the trusted communications between the connectivity client and the data center includes: conveying storage equipment performance metrics from storage equipment to the set of management servers through the connectivity client and the trusted connection, the storage equipment performance metrics identifying operating details of the storage equipment. Sundararajan in the same field of endeavor as the invention teaches a system for management of container based distributed storage systems. Sundararajan teaches wherein providing the trusted communications between the connectivity client and the data center includes: conveying storage equipment performance metrics from storage equipment to the set of management servers through the connectivity client and the trusted connection, the storage equipment performance metrics identifying operating details of the storage equipment(telemetry data regard storage performance reported for triggering remedial action, ¶123).
[0123] In the example depicted in FIG. 3A, and as described briefly above, the cloud services provider 302 may be configured to provide services to the storage system 306 and users of the storage system 306 through the usage of a SaaS service model. For example, the cloud services provider 302 may be configured to provide access to data analytics applications to the storage system 306 and users of the storage system 306. Such data analytics applications may be configured, for example, to receive vast amounts of telemetry data phoned home by the storage system 306. Such telemetry data may describe various operating characteristics of the storage system 306 and may be analyzed for a vast array of purposes including, for example, to determine the health of the storage system 306, to identify workloads that are executing on the storage system 306, to predict when the storage system 306 will run out of various resources, to recommend configuration changes, hardware or software upgrades, workflow migrations, or other actions that may improve the operation of the storage system 306.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Gupta/Halstead/Woodage with reporting of storage system telemetry as taught by Sundararajan. The reason for this modification would be to provide management of storage system performance.
Regarding claim 8, Gupta/Halstead/Woodage does not teach wherein providing the trusted communications between the connectivity client and the data center includes: performing storage equipment troubleshooting operations on the storage equipment from the set of management servers through the trusted connection and the connectivity client, the storage equipment troubleshooting operations being constructed and arranged to diagnose and remediate anomalies on the storage equipment. Sundararajan in the same field of endeavor as the invention teaches a system for management of container based distributed storage systems. Sundararajan teaches wherein providing the trusted communications between the connectivity client and the data center includes: performing storage equipment troubleshooting operations on the storage equipment from the set of management servers through the trusted connection and the connectivity client, the storage equipment troubleshooting operations being constructed and arranged to diagnose and remediate anomalies on the storage equipment(telemetry data used to trigger responsive actions to remediate anomalies, ¶s abstract,123)
[abstract]An example method for detecting and remediating anomalies in a container system by a storage system comprises detecting, by a container storage management system, a change in resources utilized on a volume of the container system by an application of the container system; determining, by the container storage management system and in response to the detecting, whether the change in resources utilized is anomalous for the application; and performing, by the container storage management system and based on the determining, an action associated with the application.
[0123] In the example depicted in FIG. 3A, and as described briefly above, the cloud services provider 302 may be configured to provide services to the storage system 306 and users of the storage system 306 through the usage of a SaaS service model. For example, the cloud services provider 302 may be configured to provide access to data analytics applications to the storage system 306 and users of the storage system 306. Such data analytics applications may be configured, for example, to receive vast amounts of telemetry data phoned home by the storage system 306. Such telemetry data may describe various operating characteristics of the storage system 306 and may be analyzed for a vast array of purposes including, for example, to determine the health of the storage system 306, to identify workloads that are executing on the storage system 306, to predict when the storage system 306 will run out of various resources, to recommend configuration changes, hardware or software upgrades, workflow migrations, or other actions that may improve the operation of the storage system 306.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Gupta/Halstead/Woodage with reporting of storage system telemetry as taught by Sundararajan. The reason for this modification would be to provide management of storage system performance.
Regarding claim 9, Gupta teaches wherein providing the trusted communications between the connectivity client and the data center includes: deploying storage equipment software from the set of management servers to the storage equipment through the trusted connection and the connectivity client, the storage equipment software being constructed and arranged to install and operate on the storage equipment to process input/output (I/O) requests on behalf of a set of host computers(client devices are network/edge nodes that provisioned to provide functions such as collecting and analyzing sensor data at the edge of a network, ¶17).
[0017] Network nodes 110 can be, for example, internet of things (IoT) type devices that can provide distributed sensor and other apparatus functionality. These devices can be configured to gather data related to their environment. Either network nodes 110 or edge services node 120 can provide computation resources to analyze and respond to data gathered by network nodes 110 closer to where the data is generated than cloud services 150. This allows for quicker responses to such data, which can be especially important for environments gathering latency sensitive information (e.g., financial services, manufacturing, and medical). This also allows for locally filtering data to only provide to cloud services 150 data that is important or necessary. This can arise, for example, in an environment where large amounts of data is produced, but most of that data is inconsequential. In addition to utilizing cloud services 150 for centralized compute, storage, and other network applications, edge computing nodes such as network nodes 110 and edge services node 120 can also utilize the cloud services for firmware and software installation, updates, and configuration.
Gupta/Halstead/Woodage do not teach conveying storage equipment performance metrics from storage equipment to the set of management servers through the connectivity client and the trusted connection, the storage equipment performance metrics identifying operating details of the storage equipment;
providing a set of user commands from the set of management servers to the storage equipment through the trusted connection and the connectivity client, the set of user commands being constructed and arranged to create a set of storage objects which hold host data on the storage equipment; and
performing storage equipment troubleshooting operations on the storage equipment from the set of management servers through the trusted connection and the connectivity client, the storage equipment troubleshooting operations being constructed and arranged to diagnose and remediate anomalies on the storage equipment.
Sundararajan in the same field of endeavor as the invention teaches a system for management of container based distributed storage systems. Sundararajan teaches
conveying storage equipment performance metrics from storage equipment to the set of management servers through the connectivity client and the trusted connection, the storage equipment performance metrics identifying operating details of the storage equipment(telemetry data regard storage performance reported for triggering remedial action, ¶123).
[0123] In the example depicted in FIG. 3A, and as described briefly above, the cloud services provider 302 may be configured to provide services to the storage system 306 and users of the storage system 306 through the usage of a SaaS service model. For example, the cloud services provider 302 may be configured to provide access to data analytics applications to the storage system 306 and users of the storage system 306. Such data analytics applications may be configured, for example, to receive vast amounts of telemetry data phoned home by the storage system 306. Such telemetry data may describe various operating characteristics of the storage system 306 and may be analyzed for a vast array of purposes including, for example, to determine the health of the storage system 306, to identify workloads that are executing on the storage system 306, to predict when the storage system 306 will run out of various resources, to recommend configuration changes, hardware or software upgrades, workflow migrations, or other actions that may improve the operation of the storage system 306.
providing a set of user commands from the set of management servers to the storage equipment through the trusted connection and the connectivity client, the set of user commands being constructed and arranged to create a set of storage objects which hold host data on the storage equipment; and( file server commands, REST API commands provide for managing storage systems where storage systems are provisioned as manage storage objects, ¶s121,132)
[0121] Although not explicitly depicted in FIG. 3A, readers will appreciate that a vast amount of additional hardware components and additional software components may be necessary to facilitate the delivery of cloud services to the storage system 306 and users of the storage system 306. For example, the storage system 306 may be coupled to (or even include) a cloud storage gateway. Such a cloud storage gateway may be embodied, for example, as hardware-based or software-based appliance that is located on premise with the storage system 306. Such a cloud storage gateway may operate as a bridge between local applications that are executing on the storage system 306 and remote, cloud-based storage that is utilized by the storage system 306. Through the use of a cloud storage gateway, organizations may move primary iSCSI or NAS to the cloud services provider 302, thereby enabling the organization to save space on their on-premises storage systems. Such a cloud storage gateway may be configured to emulate a disk array, a block-based device, a file server, or other storage system that can translate the SCSI commands, file server commands, or other appropriate command into REST-space protocols that facilitate communications with the cloud services provider 302.
[0132] The example storage system 306 depicted in FIG. 3B may implement a variety of storage architectures. For example, storage systems in accordance with some embodiments of the present disclosure may utilize block storage where data is stored in blocks, and each block essentially acts as an individual hard drive. Storage systems in accordance with some embodiments of the present disclosure may utilize object storage, where data is managed as objects. Each object may include the data itself, a variable amount of metadata, and a globally unique identifier, where object storage can be implemented at multiple levels (e.g., device level, system level, interface level). Storage systems in accordance with some embodiments of the present disclosure utilize file storage in which data is stored in a hierarchical structure. Such data may be saved in files and folders, and presented to both the system storing it and the system retrieving it in the same format.
performing storage equipment troubleshooting operations on the storage equipment from the set of management servers through the trusted connection and the connectivity client, the storage equipment troubleshooting operations being constructed and arranged to diagnose and remediate anomalies on the storage equipment(telemetry data used to trigger responsive actions to remediate anomalies, ¶s abstract,123).
[abstract]An example method for detecting and remediating anomalies in a container system by a storage system comprises detecting, by a container storage management system, a change in resources utilized on a volume of the container system by an application of the container system; determining, by the container storage management system and in response to the detecting, whether the change in resources utilized is anomalous for the application; and performing, by the container storage management system and based on the determining, an action associated with the application.
[0123] In the example depicted in FIG. 3A, and as described briefly above, the cloud services provider 302 may be configured to provide services to the storage system 306 and users of the storage system 306 through the usage of a SaaS service model. For example, the cloud services provider 302 may be configured to provide access to data analytics applications to the storage system 306 and users of the storage system 306. Such data analytics applications may be configured, for example, to receive vast amounts of telemetry data phoned home by the storage system 306. Such telemetry data may describe various operating characteristics of the storage system 306 and may be analyzed for a vast array of purposes including, for example, to determine the health of the storage system 306, to identify workloads that are executing on the storage system 306, to predict when the storage system 306 will run out of various resources, to recommend configuration changes, hardware or software upgrades, workflow migrations, or other actions that may improve the operation of the storage system 306.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Gupta/Halstead/Woodage with implementing file system configuration commands and reporting of storage system telemetry as taught by Sundararajan. The reason for this modification would be to provide configuring of storage systems and management of storage system performance.
Regarding claim 11, Gupta/Halstead/Woodage do not teach wherein the storage equipment includes: primary storage processing circuitry which includes an operating instance of the connectivity client, and secondary storage processing circuitry which includes a backup instance of the connectivity client to enable the connectivity client to continue operation in response to a failover event in which the primary storage processing circuitry encounters a failure while the secondary storage processing circuitry remains operational and the backup instance of the connectivity client takes over on behalf of the operating instance of the connectivity client.
Sundararajan in the same field of endeavor as the invention teaches a system for management of container based distributed storage systems. Sundararajan teaches wherein the storage equipment includes: primary storage processing circuitry which includes an operating instance of the connectivity client, and secondary storage processing circuitry which includes a backup instance of the connectivity client to enable the connectivity client to continue operation in response to a failover event in which the primary storage processing circuitry encounters a failure while the secondary storage processing circuitry remains operational and the backup instance of the connectivity client takes over on behalf of the operating instance of the connectivity client(storage system implement a primary and secondary controller for failover from primary to secondary in the event of failure, ¶s 39,60)
[0039] In some implementations, a primary controller, such as storage array controller 110A, may serve as the primary controller for one or more storage arrays 102A-B, and a second controller, such as storage array controller 110B, may serve as the secondary controller for the one or more storage arrays 102A-B. For example, storage array controller 110A may be the primary controller for storage array 102A and storage array 102B, and storage array controller 110B may be the secondary controller for storage array 102A and 102B. In some implementations, storage array controllers 110C and 110D (also referred to as “storage processing modules”) may neither have primary or secondary status. Storage array controllers 110C and 110D, implemented as storage processing modules, may act as a communication interface between the primary and secondary controllers (e.g., storage array controllers 110A and 110B, respectively) and storage array 102B. For example, storage array controller 110A of storage array 102A may send a write request, via SAN 158, to storage array 102B. The write request may be received by both storage array controllers 110C and 110D of storage array 102B. Storage array controllers 110C and 110D facilitate the communication, e.g., send the write request to the appropriate storage drive 171A-F. It may be noted that in some implementations storage processing modules may be used to increase the number of storage drives controlled by the primary and secondary controllers.
[0060] A storage system can consist of two storage array controllers that share a set of drives for failover purposes, or it could consist of a single storage array controller that provides a storage service that utilizes multiple drives, or it could consist of a distributed network of storage array controllers each with some number of drives or some amount of Flash storage where the storage array controllers in the network collaborate to provide a complete storage service and collaborate on various aspects of a storage service including storage allocation and garbage collection.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Gupta/Halstead/Woodage with implementing primary and secondary storage controller as taught by Sundarajan. The reason for this modification would be to provide a fault tolerant storage system.
Regarding claim 12, Gupta/Halstead/Woodage does not teach wherein the storage equipment includes: a set of storage data server (SDS) nodes, and a management platform coupled with the set of SDS nodes, the management platform including the connectivity client and being constructed and arranged to run a set of containerized applications to store data within the set of SDS nodes on behalf of a set of host computers.
Sundararajan in the same field of endeavor as the invention teaches a system for management of container based distributed storage systems. Sundararajan teaches wherein the storage equipment includes: a set of storage data server (SDS) nodes, and a management platform coupled with the set of SDS nodes, the management platform including the connectivity client and being constructed and arranged to run a set of containerized applications to store data within the set of SDS nodes on behalf of a set of host computers(distributed storage implemented as containerized software-defined storage nodes , ¶s139, 140).
[0139] The software resources 314 may also include software that is useful in implementing software-defined storage (‘SDS’). In such an example, the software resources 314 may include one or more modules of computer program instructions that, when executed, are useful in policy-based provisioning and management of data storage that is independent of the underlying hardware. Such software resources 314 may be useful in implementing storage virtualization to separate the storage hardware from the software that manages the storage hardware.
[0140] The software resources 314 may also include software that is useful in facilitating and optimizing I/O operations that are directed to the storage system 306. For example, the software resources 314 may include software modules that perform various data reduction techniques such as, for example, data compression, data deduplication, and others. The software resources 314 may include software modules that intelligently group together I/O operations to facilitate better usage of the underlying storage resource 308, software modules that perform data migration operations to migrate from within a storage system, as well as software modules that perform other functions. Such software resources 314 may be embodied as one or more software containers or in many other ways.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Gupta/Halstead/Woodage with implementing edge device storage as containerized software defined storage system as taught by Sundarajan. The reason for this modification would be to apply a well know methods for deploying storage that is easily scalable.
Claims 13-15 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta/Halstead/Woodage as applied to claim 4 above, and further in view of Shetty US 2023/0239324.
Regarding claim 13, Gupta teaches wherein registering the storage equipment as an untrusted client at the data center through the first connectivity further includes: conveying an installation token from the connectivity client to the storefront server(client provides bootstrap certificate(ie. installation token) to initiate 2nd phase of authentication, ¶30)
[0030] Once connected, the client device can provide the bootstrap certificate obtained in Phase 1 to continue with the authentication of the device with the AAA server (520). All devices that have successfully completed Phase 1 will have an appropriate bootstrap certificate to provide to the AAA server. In addition, the client device can provide device specific information to the AAA server for additional authentication. The device specific information can include, for example, device UID, manufacturer identification, serial number, and other manufacturing information to identify the specific device. The AAA server performs an initial authentication using the bootstrap certificate (530). The bootstrap certificate establishes that the client device is authorized to communicate with the AAA server. The AAA server can then use the device specific information provided by the client device to determine whether the client device is authorized to proceed further with enrollment (540). For example, the AAA server can be provided with information such as a total number of devices from a specific manufacturer allowed to communicate with the operations servers. If the client device information establishes that the device is not within the number of devices, then the AAA server can refuse to provide a security token to proceed to the next step of authorization. Similarly, the client device manufacturer can program security information (e.g., a manufacturing key or additional private keys) into the client device at manufacture time that is authenticated by the AAA server during Phase 2. The security information can be provided to the AAA server by the manufacturer for these checks. If the client device does not provide the correct security information, then the AAA server can refuse to authenticate the device. The types of authorization performed by the AAA server are not limited to the above scenarios and can be flexibly designed to provide as high a level of authentication as the operations services provider or the client device manufacturer desires for the application.
The combination of Gupta/Halstead/Woodage/Sundarajan teaches generating a temporary certificate but does not teach that the management server generates the temporary certificate and identifier and this does not teach
conveying an installation token from the connectivity client from the storefront server to the set of management servers, based on the installation token, generating the temporary identifier and the temporary certificate in the set of management servers, and
conveying the temporary identifier and the temporary certificate from the set of management servers to the storefront server for delivery from the storefront server to the connectivity client.
Shetty in the same field of endeavor as the invention teaches a system for authorizing access to content. Shetty teaches conveying an installation token from the connectivity client from the storefront server to the set of management servers, based on the installation token, generating the temporary identifier and the temporary certificate in the set of management servers, and(temporary identifier representing authentication result transferred to management server by identity server(storefront), management server generations UEM session token, ¶56)
[0056] At stage 322, the management server 142 can send a UEM session token to the identity manager 144. The UEM session token can be a security token generated in the management server 142 that the management application 120 can recognize and validate, thereby adding another layer of security. In one example, the management application 130 can be provided with a security key for decrypting the UEM session token during or after enrollment. As an example, each enrolled user device in the UEM system 140 can be configured with an encrypted key pair. Each enrolled user device can possess a private key and the UEM system 140 can store a copy of each corresponding public key. The UEM system can encrypt communications with each user device using their corresponding public key. In an example, the management server 142 can encrypt the UEM session key using the public key that corresponds to the user device 110 so that only the management application 120 on the user device 110 can decrypt the UEM session key.
conveying the temporary identifier and the temporary certificate from the set of management servers to the storefront server for delivery from the storefront server to the connectivity client(UEM session key and temp key sent to identity server(storefront) and then further to client for subsequent authentication) .
[0056] At stage 322, the management server 142 can send a UEM session token to the identity manager 144. The UEM session token can be a security token generated in the management server 142 that the management application 120 can recognize and validate, thereby adding another layer of security. In one example, the management application 130 can be provided with a security key for decrypting the UEM session token during or after enrollment. As an example, each enrolled user device in the UEM system 140 can be configured with an encrypted key pair. Each enrolled user device can possess a private key and the UEM system 140 can store a copy of each corresponding public key. The UEM system can encrypt communications with each user device using their corresponding public key. In an example, the management server 142 can encrypt the UEM session key using the public key that corresponds to the user device 110 so that only the management application 120 on the user device 110 can decrypt the UEM session key.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Gupta/Halstead/Woodage with generating the temporary certificate at the E-EST server of Gupta as taught by Shetty. The reason for this modification would be to provide an additional level of security(see Shetty ¶44).
Regarding claim 14, Shetty teaches wherein registering the storage equipment as an untrusted client at the data center through the first connectivity further includes: prior to delivering the temporary identifier and the temporary certificate from the storefront server to the connectivity client, storing the temporary identifier and the temporary certificate in the set of management servers to enable the set of management servers to perform the handshaking and validation operations to form the trusted connection(Management server stores session token and temp token which is later used for access authentication with the user device/client, ¶s61,62).
[0061] At stage 336, the management application 120 can send the UEM session token, temporary token, and a user session token to the management server 142. In an example, the user session token can refer to a token provided by the management application 120 that is verifiable by the UEM system 130. For example, the user session token can be provided to the management application 120 during or after enrollment from the management server 142. In one example, the management application 120 can encrypt the tokens using a public key provided by the management server 142. The management server 142 can decrypt the tokens using a corresponding private key.
[0062] At stage 338, the management server 142 can validate the tokens. For example, the management server 142 can verify that the UEM session token is the same token previously given to the identity manager 144, that the user session token matches a user session token associated with the user device 110, and that the temporary token received from the user device 110 matches the temporary token received from the identity manager 144. In one example, the management server 142 can also verify that the temporary token has not expired.
Regarding claim 15, Gupta teaches a client device with the software to initiate enrollment and thus does not teach prior to registering the storage equipment as an untrusted client at the data center, installing and activating the connectivity client on the storage equipment. Shetty in the same field of endeavor as the invention teaches a system for authorizing access to content. Shetty teaches prior to registering the storage equipment as an untrusted client at the data center, installing and activating the connectivity client on the storage equipment.
[0018] In an example, a management server in the UEM system can act on the ERE's recommendations based on the policies. For example, if a policy states that an extension is not mandatory, then the management server can send a notification or message to the user identifying the recommendation and stating why the extension is recommended. In an example where the extension is required, the management server can send to the user device an install file or a Uniform Resource Locator (“URL”) for downloading the install file. The file or URL can be sent to the management application, the UEM extension, or the browser, depending on the example. In one example, the management server can send instructions to the management application to block internet access on the user device unless the mandatory extension is installed.
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Gupta/Halstead/Woodage with installing a connectivity client(UEM extension) prior to initiating enrollment. The reason for this modification would be to install a program for facilitating enrollment when the client does not have a connectivity client(UEM extension installed).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Tom Y. Chang whose telephone number is 571-270-5938. The examiner can normally be reached on Monday-Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emmanuel Moise , can be reached on (571)272-7872. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/TOM Y CHANG/
Primary Examiner, Art Unit 2455