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 office correspondence is in response to “Amendment and Response under 37 C.F.R. 1.111 filed on September 8, 2025 in response to a non-final office action dated June 9, 2025.
Claims 1 – 17 are pending.
Claims 1, 4, 6, and 14 are amended.
Claims 16 – 17 are added.
Claims 1 – 17 are rejected.
Response to Arguments
Applicant’s arguments filed on 9/08/2025 have been fully considered:
In regard to claims 1 – 15 which were rejected under 35 U.S.C. 103 at least one argument is persuasive to the rejection of claims from the last office action and said rejections are withdrawn, but applicant’s amendment necessitated a new search and consideration resulting in a new grounds of rejections for claims 1 – 17 under 35 U.S.C. 103. The examiner here now responds to each argument. Underlined text indicates claim language that was amended since the last office action.
In regard to claims 1 – 4, 6 – 7, 9 – 12, and 14 the applicant argues that the prior art combination of Polyakov and Reagan fails to teach, anticipate or suggest:
“ retrieve the previously user-provided configuration information for the operating system from the secure storage device.” (as recited in claim1 and substantially replicated in claims 9 and 14)
The applicant states (for claim 1)
“ . . . Applicant respectfully asserts that Polyakov in view of Reagan fails to teach or suggest at least the above-emphasized elements of claim 1. In particular, Polyakov in view of Reagan fails to teach or suggest retrieving previously user-provided configuration information for an operating system from a secure storage device, and automatically configuring the operating system according to the previously user-provided configuration information. For example, paragraph [0012] of the as-filed specification describes that previously user-provided configuration information is stored “on a secure storage device of the computing device.” This user-provided configuration information is further described in paragraph [0015] as information that is collected “at first user power-on of [a] device.” Applicant respectfully asserts that neither Polyakov nor Reagan mention accessing such information that is used for automatically configuring an operating system of a device.
In the rejection of the subject matter of dependent claim 6, which has been amended into independent claim 1, the Office Action alleges that Polyakov teaches retrieving previously user- provided configuration information for an operating system in paragraph [0030]. See Office Action, p. 12. Paragraph [0030] of Polyakov describes accessing configuration information from a manufacturer boot environment. In particular, paragraph [0030] of Polyakov defines the boot configuration as “using boot variables 157 stored in a portion of the data store 163.” That is, Polyakov utilizes information provided in a data store, rather than user-specific configuration information previously-provided by the user of the computing device. Reagan fails to remedy this shortfall of Polyakov.
For at least the above reasons, Applicant respectfully submits that independent claim 1 is patentable over Polyakov in view of Reagan. Additionally, claims 2-8 and 16-17, depend from claim 1 and are patentable over Polyakov in view of Reagan, alone or in combination with any of the other cited references. Accordingly, Applicant respectfully requests withdrawal of the rejections of claims 1-8 and allowance of claims 1-8 and 16-17. . . (Applicant’s remarks page 8).
The applicant states (for claim 9)
“ . . . Applicant respectfully asserts that Polyakov in view of Reagan fails to teach or suggest at least the above-emphasized elements of claim 9. In particular, Polyakov in view of Reagan fails to teach or suggest the retrieval of previously user provided configuration information in accordance with which an operating system of the computing device is to be automatically configured at first user power-on of the computing device. Applicant submits that the above remarks made with respect to independent claim 1 similarly apply to independent claim 9.
The Office Action alleges that Polyakov teaches the retrieval of previously user-provided
configuration information in accordance with which an operating system of the computing device in paragraph [0021]. See Office Action, p. 15. In particular, paragraph [0021] of Polyakov describes a management agent that determines a state of a client device, such as “a list of client applications installed, running or displayed on the client device,” as well as “a list of hardware settings of the client device.” Applicant respectfully asserts that paragraph [0021] merely discusses the determination and observation of an operation of a client device, and fails to mention retrieving
user-provided configuration information. Reagan fails to remedy this shortfall of Polyakov.
For at least the above reasons, Applicant respectfully submits that independent claim 9 is patentable over Polyakov in view of Reagan. Additionally, claims 10-13, depend from claim 9 and are patentable over Polyakov in view of Reagan, alone or in combination with any of the other cited references. Accordingly, Applicant respectfully requests withdrawal of the rejections of and the allowance of claims 9-13. . . .” (Applicant’s remarks 9 – 10).
The applicant states (for claim 14)
“ . . .Applicant respectfully asserts that Polyakov in view of Reagan fails to teach or suggest at least the above-emphasized elements of claim 14. Polyakov in view of Reagan fails to teach or suggest storing configuration information, received from a user, on a server for retrieval by and subsequent storage on a computing device. In particular, the Office alleges that paragraphs [0012], [0013]-[0014], and [0028] of Polyakov teach the above-emphasized elements of claim 14 See Office Action, p. 23-34. However, the cited portions of Polyakov merely discuss a data store. Included on a client device. See Polyakov, par. [0028]. The data store of Polyakov fails to teach or suggest the claimed retrieval and storage of configuration information. Applicant submits that the above remarks made with respect to independent claims 1 and 9 similarly apply to independent claim 14. For at least the above reasons, Applicant respectfully submits that independent claim 14 is patentable over Polyakov in view of Reagan. Additionally, claim 15 depends from claim 14 and is patentable over Polyakov in view of Reagan, alone or in combination with any of the other cited references. Accordingly, Applicant respectfully requests withdrawal of the rejections of and the allowance of claims 14 and 15. . .” (applicant’s remarks 10 – 11)
In response to the applicant’s arguments:
The applicant amended independent claim 1 to incorporate dependent claim 6 and argues the prior art (particularly Polyakov) does not teach retrieving previously provided user provided configuration information for an operating system. The other independent claims 9 and 14 comprises similar functionality. Upon review of applicant’s arguments directed to retrieving previously provided user provided configuration information, the applicant’s arguments were persuasive to overcome the 35 U.S.C. rejection as being unpatentable over Polyakov and Reagan, and trigger a new search and consideration that discovered new grounds of rejection under 35 U.S.C. 103 and said claims are therein rejected as being unpatentable over Polyakov et al. (U.S. 2020/0387385 A1; herein referred to as Polykov) in view of Reagan et al. (U.S. 10,445,082 B2; herein referred to as Reagan) in further view of Balakrishnan et al. (U.S. 2015/0178095 A1; herein referred to as Balakrishnan). The new prior art Balakrishnan is analogous art directed to systems, devices, and methods for automatically configuring baseboard management controllers (BMC) from user provided configurations that are stored on a central management system and retrieved when necessary to go online. When combined with the prior art of Polykov and Reagan, the automatic configuration activities of Balakrishnan directed to BMCs of device clusters teach a retrieving of user configurable data, the target baseboard management controller comprising an operating system for the device. Balakrishnan teaches a series of steps to complete the configuration – see Balakrishnan including ¶¶ [0007-0008], ¶¶ [0056-0063], ¶ [0089] as described for the rejections below.
The applicant also added dependent claims 16 – 17 which required a new search and consideration.
Therein the rejection for the amended claim sets comprise:
Claims 1 – 4, 6 – 7, 9 – 12, and 14 are rejected under 35 U.S.C. 103 as being un-patentable over Polyakov et al. (U.S. 2020/0387385 A1; herein referred to as Polykov) in view of Reagan et al. (U.S. 10,445,082 B2; herein referred to as Reagan) in further view of Balakrishnan et al. (U.S. 2015/0178095 A1; herein referred to as Balakrishnan).
Claim 5 is rejected under 35 U.S.C. 103 as being un-patentable over Polyakov et al. (U.S. 2020/0387385 A1; herein referred to as Polykov) in view of Reagan et al. (U.S. 10,445,082 B2; herein referred to as Reagan) in further view of Balakrishnan et al. (U.S. 2015/0178095 A1; herein referred to as Balakrishnan) as applied to claims 1 – 4, 6 – 7, 9 – 12, and 14 in further view of Griffin (U.S. 2013/0040729 A1; herein referred to as Griffin).
Claim 8 is rejected under 35 U.S.C. 103 as being un-patentable over Polyakov et al. (U.S. 2020/0387385 A1; herein referred to as Polykov) in view of Reagan et al. (U.S. 10,445,082 B2; herein referred to as Reagan) in further view of Balakrishnan et al. (U.S. 2015/0178095 A1; herein referred to as Balakrishnan) as applied to claims 1 – 4, 6 – 7, 9 – 12, and 14 in further view of Liu et al. (U.S. 2019/0339988 A1; herein referred to as Liu).
Claims 13 and 15 are rejected under 35 U.S.C. 103 as being un-patentable over Polyakov et al. (U.S. 2020/0387385 A1; herein referred to as Polykov) in view of Reagan et al. (U.S. 10,445,082 B2; herein referred to as Reagan) in further view of Balakrishnan et al. (U.S. 2015/0178095 A1; herein referred to as Balakrishnan) as applied to claims 1 – 4, 6 – 7, 9 – 12, and 14 in further view of Ryu et al. (U.S. 2004/0103042 A1; herein referred to as Ryu).
Claims 16 – 17 are rejected under 35 U.S.C. 103 as being un-patentable over Polyakov et al. (U.S. 2020/0387385 A1; herein referred to as Polykov) in view of Reagan et al. (U.S. 10,445,082 B2; herein referred to as Reagan) in further view of Balakrishnan et al. (U.S. 2015/0178095 A1; herein referred to as Balakrishnan) as applied to claims 1 – 4, 6 – 7, 9 – 12, and 14 in further view of Moore et al. (U.S. 2011/0179372 A1; herein referred to as Moore).
The examiner recommends that the applicant review the specification for disclosure that if integrated into the independent claims would distinguish the amended claims from the cited prior art. The applicant is invited to contact the examiner for an interview to discuss how to move the prosecution forward.
Authorization for Internet Communications
The examiner encourages Applicant to submit an authorization to communicate with the examiner via the Internet by making the following statement (from MPEP 502.03):
“Recognizing that Internet communications are not secure, I hereby authorize the USPTO to communicate with the undersigned and practitioners in accordance with 37 CFR 1.33 and 37 CFR 1.34 concerning any subject matter of this application by video conferencing, instant messaging, or electronic mail. I understand that a copy of these communications will be made of record in the application file.”
Please note that the above statement can only be submitted via Central Fax (not Examiner's Fax), Regular postal mail, or EFS Web using PTO/SB/439.
Priority
This application is a National Stage entry from PCT application PCT/US2021/027673 filed on April 16, 2021. Therein, the applicant is entitled to a priority date of 4/16/2021.
35 USC § 101 Analysis
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
The claimed invention is directed to statutory subject matter and are not rejected under 35 USC 101 because of a judicial exception.. The claimed subject matter is integrated into a practical application under prong 2 of the Step 2A analysis as documented in MPEP 2016.04(d). The claims are directed to non-abstract improvements in computer related technology. A claim is non-statutory when it is directed to a judicial exception (e.g. either one of mathematical concepts, mental processes, or certain methods of organizing human activity) without significantly more. The claimed invention is not directed to a judicial exception. Instead, the claimed invention is directed to a technological improvement for providing initial configuration and registration of a computing device’s operating system wherein the device comprises a storage device storing an operating system, a secure storage device storing previously user-provided configuration information for the operating system, a username, and a security token, a processor, and a memory storing instructions executable by the processor to perform a method that upon initial assignment of a computing device to a user, performing power-on of the computing device prior to providing the computing device to the user, and upon the power-on of the computing device, causing the computing device to retrieve, from a server previously user-provided configuration information in accordance with which an operating system of the computing device is to be automatically configured at first user power-on of the computing device without manual user input at the computing device. Additionally, the computing device will retrieve a username with which the operating system is to be automatically registered at the first user power-on without user interaction, and a security token as a single-use password with which the operating system is to be automatically registered at the first user power-on without the user interaction. Therein, responsively causing the computing device to store the previously user-provided configuration information, the username, and the security token that have been retrieved from the server on a secure storage device of the computing device, and performing power-down of the computing device and providing the computing device to the user. The ordered steps of the claim language impose meaningful limits on the scope of the claims and provides an improvement for a user operating a computing device for the first time so that at first user power-on of the computing device, the operating system of the computing device is automatically configured according to the previously user-provided configuration information without manual user input of such information at the computing device. The operating system is automatically registered with the username and the security token without user interaction, where the security token serves as a single-use password for logging into the operating system. Therein the claimed invention is statutory.
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 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 of this title, 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 – 4, 6 – 7, 9 – 12, and 14 are rejected under 35 U.S.C. 103 as being un-patentable over Polyakov et al. (U.S. 2020/0387385 A1; herein referred to as Polykov) in view of Reagan et al. (U.S. 10,445,082 B2; herein referred to as Reagan) in further view of Balakrishnan et al. (U.S. 2015/0178095 A1; herein referred to as Balakrishnan).
In regard to claim 1, Polykov teaches A computing device (see Fig. 1 client device 109) comprising:
a storage device storing an operating system (see ¶ [0028] “ . . . The client device 109 can include a data store 163. The data store 163 can represent memory devices including, for example, random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, USB flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape or other memory components. The data store 163 can include a main operating system 164, a manufacturer boot environment 165, management components 146, boot variables 157, policies 131, enrollment data 161, client applications, and other data. . . .”);
a secure storage device storing previously user-provided configuration information for the operating system, a username, and a security token (see ¶¶ [0025-0026] “ . . . Enrollment data 161 can include information for enrollment of a client device 109 with the management service 120. The enrollment data 161 can include an enrollment token like a character string, value, parameter, or file that can be used to authenticate the client device 109 with the management service 120. In some cases, the management service 120 can provide enrollment tokens corresponding to each of the client devices 109 and/or users that have a user account with the enterprise. To this end, a request for an enrollment token can be required to include a device identifier, username, password, or other information. An enrollment token can be valid during a certain time period after which the enrollment token can expire. Enrollment data 161 can also include a network address or other information to facilitate communication between the client device 109 and the management service 120. Enrollment data 161 can also include a network endpoint address and other instructions for communications with the management service 120. The enrollment data 161 can be transmitted to the client device 109 and stored in the data store 163 . . .”);
a processor; and a memory storing instructions executable by the processor (see ¶ [0072] “ . . . A number of software components are stored in the memory and executable by a processor. In this respect, the term “executable” means a program file that is in a form that can ultimately be run by the processor. Examples of executable programs can be, for example, a compiled program that can be translated into machine code in a format that can be loaded into a random access portion of one or more of the memory devices and run by the processor. This code can be expressed in a format such as object code that is capable of being loaded into a random access portion of the one or more memory devices and executed by the processor, or code that can be interpreted by another executable program to generate instructions in a random access portion of the memory devices to be executed by the processor. An executable program can be stored in any portion or component of the memory devices including, for example, random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, USB flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape or other memory components . . .”) to:
retrieve (see ¶ [0030] “ . . . “ . . . The manufacturer boot environment 165 can be a recovery or setup operating system that complies with Extensible Firmware Interface (EFI), Unified Extensible Firmware Interface (UEFI), or another extensible firmware specification. The manufacturer boot environment 165 can utilize a boot manager or boor process that checks a boot configuration of the client device 109, loads manufacturer boot environment 165 into memory, and executes the manufacturer boot environment 165. The boot configuration can be defined using boot variables 157 stored in a portion of the data store 163, which can include a nonvolatile memory area. The manufacturer boot environment 165 be loaded from the data store 163, such as an EFI or UEFI system partition of the hard drive, or a dedicated memory area separate from the hard drive. The manufacturer boot environment 165 can also load from a location accessed through the network 112 using network boot or HTTP boot functionality. This can allow the manufacturer boot environment 165 to persist through hard drive errors or replacement and other critical system crashes and events. The manufacturer boot environment 165 can be a persistent boot environment installed by the manufacturer. . . “)
at (e.g. out-of-box experience) (see ¶ [0045] “ . . . The management application 149 can enroll the client device 109 with the management service 120. In some cases, this can be part of an operating system setup process or out-of-box experience of the main operating system 164.. . . “), automatically configure the operating system according to the previously user-provided configuration information (see ¶ [0035] “ . . . The management application 149 can be a management component 146 that can execute from the main operating system 164. The management application 149 can perform actions on the client device 109. For instance, the management application 149 can enroll the client device 109 with the management service 120. The management application 149 can transmit an enrollment request to an enrollment endpoint of the management service 120. The enrollment request can include an enrollment token and a device identifier of the client device 109. The management application 149 can receive and install an enrollment policy 131 to complete enrollment. The enrollment policy 131 can be transmitted from the management service 120 to the client device 109. The management application 149 can perform enrollment during the out of box experience (DOBE) or startup configuration process of the main operating system 164 . . .”) so that the operating system is configured without manual user input at the computing device (see Fig. 3, ¶¶ [0058-0059] “ . . In step 309, the management agent 147 can transmit provisioning telemetry data to the management service 120. The provisioning telemetry data can include information relevant to the provisioning of the client device 109. For example, the provisioning telemetry data can include a client device model identification, a manufacturer boot environment identification, a main operating system identification, a management application identification, a total provisioning time, and a provisioning result identification. The model identification of the client device 109 can include a model number assigned by the manufacturer, a unique device identifier of the client device 109 assigned by the management service 120, and other identifications. The manufacturer boot environment identification can include a product name and a version of the manufacturer boot environment 165. The main operating system identification can include a product name and a version of the main operating system 164. The total provisioning time can include a duration from a last boot time to the completion of the installation of the management application 149. Alternatively, the total provisioning time can refer to a duration from execution of the management agent 147 to the completion of the installation of the management application 149. The provisioning result identification can identify whether provisioning was successful or unsuccessful, for example, whether the management application 149 was successfully installed, or if the installation failed. In step 312, the management agent 147 can set provisioning variables. If the management application 149 was successfully installed, the management agent 147 can set the provisioning status variable to indicate that the client device 109 is provisioned for management by the management service 120 . . .”); and
automatically register (e.g. enrollment process) the operating system with the username and with the security token as a single-use password without user interaction (see ¶ [0062] “ . . . The enrollment process 402 describes how the management application 149 can enroll the client device 109 with the management service 120. An out-of-box-experience of the main operating system 164 can include a simple guided user interface to setup the main operating system 164. The enrollment process 402 can be performed during an out-of-box experience of the client device 109, or immediately thereafter. For example, the out-of-box experience can be modified to include the enrollment process 402, or the enrollment process 409 can begin thereafter. In some examples, a user interface can be displayed during the enrollment process 409, which can notify a user of a status of the enrollment process. User inputs including a personal identification number (PIN), a username and password, or other credentials can be obtained. In other examples, the enrollment process 402 can be completed automatically, without user input . . .”).
Polyakov fails to explicitly teach but Reagan teaches at first power on (see Col 5: Lines 32-39 “ . . . should a client device 106 that has been powered on in a factory reset condition, or with no user data or device profile data provisioned upon the client device 106, the client device 106 can communicate with the device discovery computing environment 109 in order to discover the network address of a registration server 121 with which it should communicate in order to enroll itself with a management system 119. . . “).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s application to incorporate systems, devices, and methods directed to a persistent enrollment of a device in a management system where upon detection of a triggering event, detection of whether an agent application is installed performed so that the agent application can then complete an enrollment of the device with a management system, where certain components of such a process can be bundled with the device operating system or as a system application, as taught by Reagan, into systems, devices, and methods directed to persistent device provisioning, where a management agent is executed from the manufacturer boot environment, and the management agent determines that a main operating system of the client device is currently un-provisioned for management by the management service, so that the management agent installs a management application that is executable in the main operating system, and the client device boots to the main operating system and executes the management application so that the management application enrolls the client device with the management service by installing an enrollment token received from the management service, as taught by Polyakov. Such incorporation enables a method that can be deployed to install and configure new computing devices.
The combination of Polykov and Reagan fails to explicitly teach,
However Balakrishnan teaches retrieve the previously user-provided configuration information for the operating system from the secure storage device (see Balakrishnan ¶ [0007]” . . . configuring a plurality of baseboard management controllers (BMCs) installed on a plurality of clusters of managed devices. . . ; see ¶ [0008]” . . . allow a user to provide one set of BMC configuration information to each of the plurality of clusters of managed devices; a master BMC configuration database configured to store the set of BMC configuration information for each of the plurality of clusters of managed devices received from the plurality of input interfaces; a plurality of output interfaces configured to communicate with each master managed device of each cluster of managed devices; and a master BMC configuration module constructed to configure the BMCs installed on each master managed device of each cluster through the plurality of output interfaces. . . .” see ¶¶ [0056-0063]” . . . The initial information received from the user includes: the number of clusters, the number of managed devices in each of these clusters, the IP address of all managed devices (including one master managed device and one or more slave managed devices in various clusters networked with the synchronous BMC configuration system 100, and initial BMC configuration information for each of the BMC on the master managed devices for each cluster. The BMC is configured to perform one or more of following platform management functions: Remote access to the BMC through the system's serial port and integrated network interface card (NIC) Fault logging and Simple Network Management Protocol (SNMP) alerting through Platform Event Filters (PEFs) Access to the system event log (SEL) and access to sensor status information Control of system functions, including power-up and power-down Support that is independent of the system's power up operating state Text console redirection for system setup, text based utilities, and operating system (OS) consoles . . .”; see ¶ [0089] “ . . . the master BMC configuration module 240 includes: (a) a communication interface 241, and (b) a discovery module 242. The communication interface 241 facilitates the communication from the user through the set of input interfaces, and to the master and slave managed devices of each cluster of managed devices. The discovery module 242 of the master BMC configuration module 240 is used to discover all master managed devices of each cluster of managed devices based on the BMC configuration information received from the user and/or retrieved from the master BMC configuration database 250, such as the number of clusters, the number of slave managed devices in each cluster of managed devices, the IP addresses of the master and slave managed devices of each cluster of managed devices . . . “ )
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s application to incorporate systems, devices, and methods for automatically configuring baseboard management controllers (BMC) from user provided configurations that are stored on a central management system and retrieved when necessary to go online, as taught by Balakrishnan, into systems, devices, and methods directed to persistent device provisioning, where a management agent is executed from the manufacturer boot environment, and the management agent determines that a main operating system of the client device is currently un-provisioned for management by the management service, so that the management agent installs a management application that is executable in the main operating system, and the client device boots to the main operating system and executes the management application so that the management application enrolls the client device with the management service by installing an enrollment token received from the management service, and upon detection of a triggering event, detection of whether the management agent application is installed so that the agent application can then complete an enrollment of the device with a management system, where certain components of such a process can be bundled with the device operating system or as a system application, as taught by the combination of Polyakov and Reagan. Such incorporation enables user specific configuration information to be retrieved and used upon startup of a device.
In regard to claim 2, the combination of Polyakov, Reagan and Balakrishnan teaches wherein the instructions are executable by the processor to further:
at the first user power-on of the computing device (see Reagan Col 5: Lines 32-39 as described for the rejection of claim 1 and is incorporated herein), first-time execute the operating system on the computing device (see Polyakov ¶ [0009] “ . . . Provisioning can refer to installation and configuration of management components that enable management by a management service. The managing components can include components that execute in a manufacturer boot environment and a main operating system, respectively . . .”), wherein automatic configuration and registration of the operating system occur during first-time execution of the operating system (see Polyakov ¶ [0035] “ . . . The management application 149 can be a management component 146 that can execute from the main operating system 164. The management application 149 can perform actions on the client device 109. For instance, the management application 149 can enroll the client device 109 with the management service 120. The management application 149 can transmit an enrollment request to an enrollment endpoint of the management service 120. The enrollment request can include an enrollment token and a device identifier of the client device 109. The management application 149 can receive and install an enrollment policy 131 to complete enrollment. The enrollment policy 131 can be transmitted from the management service 120 to the client device 109. The management application 149 can perform enrollment during the out of box experience (DOBE) or startup configuration process of the main operating system 164. . . .”).
The motivation to combine Reagan with Polyakov is described for the rejection of claim 1 and is incorporated herein.
In regard to claim 3, the combination of Polyakov, Reagan and Balakrishnan teaches wherein the instructions are executable by the processor to further:
at the first user power-on of the computing device (see Reagan Col 5: Lines 32-39 as described for the rejection of claim 1 and is incorporated herein), initially install the operating system on the computing device (see ¶ [0034] “ . . . The local versions of the management components 146 can be manufacturer-installed on the client device 109. The management agent 147 can be considered a component of the manufacturer boot environment 165, and can be executed by the manufacturer boot environment 165. The management agent 147 can be compatible with a framework supported by the manufacturer boot environment 165. For instance, the manufacturer boot environment 165 can support a particular .NET Framework such as .NET 4.5. In addition, the management agent 147 can operate in the absence of features that are unsupported by the manufacturer boot environment 165, such as a scheduling service. The management agent 147 can be utilized to provision the main operating system 164. For example, the management agent 147 can install the management application 149 and obtain the enrollment data 161 from the management service 120 . . .”) prior to the first-time execution the operating system (see Polyakov ¶ [0009] “ . . . Provisioning can refer to installation and configuration of management components that enable management by a management service. The managing components can include components that execute in a manufacturer boot environment and a main operating system, respectively . . .”),
wherein the automatic configuration of the operating system according to the previously user-provided configuration information (see Polyakov ¶ [0035] “ . . . The management application 149 can be a management component 146 that can execute from the main operating system 164. The management application 149 can perform actions on the client device 109. For instance, the management application 149 can enroll the client device 109 with the management service 120. The management application 149 can transmit an enrollment request to an enrollment endpoint of the management service 120. The enrollment request can include an enrollment token and a device identifier of the client device 109. The management application 149 can receive and install an enrollment policy 131 to complete enrollment. The enrollment policy 131 can be transmitted from the management service 120 to the client device 109. The management application 149 can perform enrollment during the out of box experience (DOBE) or startup configuration process of the main operating system 164. . . .”) further occurs during installation of the operating system ((see Polyakov ¶ [0057] “ . . . the management agent 147 can install the management application 149 for execution from the main operating system 164. For example, the management agent 147 can unpack an installation file or compressed file of the management application 149 to a particular folder or memory location on the data store 163 . . .”)
In regard to claim 4, the combination of Polyakov, Reagan and Balakrishnan teaches wherein the instructions are executed as part of at least one of first-time execution or initial installation of the operating system on the computing device (see Reagan Col 6: Lines 42 – 62 “ . . . The client device 106 may be configured to execute an operating system 140, an activator application 142, an agent application 143, and/or other components. The operating system 140 can include a device operating system that is bundled with the client device 106 by an OEM, a carrier, distributor, or any other entity. The loader service 141 comprises a software application, module, library, operating system capability or any other software that can be installed upon the client device 106 as a part of the operating system or as a system application that is not user modifiable without root or administrator privileges. The loader service 141 is executed as a part of or in association with the operating system in order to detect startup or any other triggering event associated with the client device 106, whether by detecting a power-on of the client device 106, a startup of the operating system 140, a location parameter of the client device 106, receipt of a command from the management system 119, or any other triggering event. Upon detecting a triggering event, the loader service 141 determines whether the activator application 142 is installed upon the client device 106. . . “).
The motivation to combine Reagan with Polyakov and Balakrishnan is described for the rejection of claim 1 and is incorporated herein. Additionally, Reagan provides first time power -up installation of the operating system.
In regard to claim 6, the combination of Polyakov, Reagan and Balakrishnan teaches retrieve the username and the security token (e.g. password) from the secure storage device (see Reagan Col 4: Lines 58-61 “ . . . the device data 133 can also include other user account data, such as a username, password, other authentication credentials or other user data that may be stored in association with a user account.
The motivation to combine Reagan with Polyakov and Balakrishnan is described for the rejection of claim 1 and is incorporated herein. Additionally, Reagan explicitly assures a username and password are retrieved from the central security device to the device.
In regard to claim 7, the combination of Polyakov, Reagan, and Balakrishnan teaches wherein the previously user-provided configuration information for the operating system, the username, and the security token are retrieved from the secure storage device via a management instrumentation service provided by the operating system (see Polyakov ¶¶ [0021-0023] “ . . . The management service 120 can communicate with the management agent 147 and management application 149 to determine which states exist on the client device 109. The states can include a list of client applications that are installed, running or displayed on the client device 109. Additional states can include a list of hardware settings of the client device 109. The list of hardware settings can identify whether a hardware device of the client device 109 is enabled or disabled. For instance, a security policy 131 can require a particular hardware setting for a Bluetooth device, a WiFi device, an infrared device, a camera device, an audio recording device, a speaker device, a near-field communication (NFC) device, a radio-frequency identification (RFID) device or another hardware device. The policies 131 can permit or deny any of the states of the client device. For example, a policy 131 can require that one or a group of the hardware devices are enabled or disabled. The states can also include software settings of the client device 109. A list of software settings can identify whether a software functionality of the client device 109 is enabled or disabled. The software functionality can be provided by an operating system of the client device 109 or other instructions executed on the client device 109. An enterprise can operate the management service 120 to oversee or manage the provisioning and operation of the client devices 109. The management service 120 can remotely configure the client device 109 by interacting with a management application 149 or another client application executed on the client device 109. The management service 120 can transmit various software components, including the current version of the management components 146, to the client device 109. These can be installed or configured by the manufacturer boot environment 165, and by the local version of the management components 146 that are already installed on the client device 109. Additional software components can include, for example, additional client applications, resources, libraries, drivers, device configurations, or other similar components that require installation on the client device 109 as specified by an administrator of the management service 120. The management service 120 can further cause policies 131 to be enforced on a client device 109. Policies 131 can include device-specific or user-specific settings, for example, restrictions or permissions pertaining to capabilities of a client device 109. For instance, policies 131 can require certain hardware or software functions of the client device 109 to be enabled or disabled during a certain time period or when the client device 109 is physically located at a particular location. Such policies can be implemented by the management application 149. Policies 131 can also include an enrollment policy 131 that indicates the client device 109 is enrolled with the management service 120. The management components 146 can include current versions of the management agent 147 and the management application 149. These components can include instructions designed to execute on client device 109 in order to perform management commands in concert with the management service 120. The management agent 147 can be a management component 146 that is executable from the manufacturer boot environment 165 of the client device 109. The management application 149 can be a management component 146 that is executable from the main operating system 164 of the client device 109. . . “).
In regard to claim 9, Polyakov teaches A method (see abstract “ . . . various examples for persistent device provisioning . . .”) comprising:
upon initial assignment of a computing device to a user (see ¶ [0009] “ . . . The present disclosure describes mechanisms that enable persistent device provisioning and enrollment. These mechanisms can provision and enroll a client device on initial startup, and following events that disrupt the provisioning status of the client device. . . .”), performing power-on of the computing device prior to providing the computing device to the user (see ¶ [0022] “ . . . An enterprise can operate the management service 120 to oversee or manage the provisioning and operation of the client devices 109. The management service 120 can remotely configure the client device 109 by interacting with a management application 149 or another client application executed on the client device 109. The management service 120 can transmit various software components, including the current version of the management components 146, to the client device 109. These can be installed or configured by the manufacturer boot environment 165 . . policies 131 can require certain hardware or software functions of the client device 109 to be enabled or disabled during a certain time period or when the client device 109 is physically located at a particular location. . . .” (e.g. factory location) ;
upon the power-on of the computing device, causing the computing device to retrieve, from a server (see Fig. 1 management system 103) (see ¶ [0012] “ . . . The management system 103 can include a server computer or any other system providing computing capability. . . .”; see ¶¶ [0013-0014]” . . . The management system 103 can execute a management service 120 to oversee management of the client devices 109. The components executed on the management system 103 can include the management service 120, as well as other applications, services, processes, systems, engines or functionality not discussed in detail. An enterprise, such as one or more companies or other organizations, can operate the management service 120 to oversee or manage the operation of the client devices 109 of its employees, contractors, customers, students or other users having user accounts with the enterprise. An enterprise can include any customer of the management service 120. The management service 120 can have a command queue storing an action to perform on a particular client device 109 upon check-in of the client device 109 . . .”) :
is to be automatically configured (e.g. device data) (see ¶ [0018] “ . . . device data 125 can include data associated with a configuration of a client device 109 enrolled or managed by the management service 120 as well as an identifier of the client device 109. The identifier can be a serial number, media access control (MAC) address, other network address or other device identifier. In addition, the device data 125 can include an enrollment status indicating whether a client device 109 has been enrolled with the management service . . .”; (see ¶ [0021] “ . . . The management service 120 can communicate with the management agent 147 and management application 149 to determine which states exist on the client device 109. The states can include a list of client applications that are installed, running or displayed on the client device 109. Additional states can include a list of hardware settings of the client device 109. The list of hardware settings can identify whether a hardware device of the client device 109 is enabled or disabled. For instance, a security policy 131 can require a particular hardware setting for a Bluetooth device, a WiFi device, an infrared device, a camera device, an audio recording device, a speaker device, a near-field communication (NFC) device, a radio-frequency identification (RFID) device or another hardware device. The policies 131 can permit or deny any of the states of the client device. For example, a policy 131 can require that one or a group of the hardware devices are enabled or disabled. The states can also include software settings of the client device 109. A list of software settings can identify whether a software functionality of the client device 109 is enabled or disabled. The software functionality can be provided by an operating system of the client device 109 or other instructions executed on the client device 109. . . “)) at((e.g. out-of-box experience) (see ¶ [0045] “ . . . The management application 149 can enroll the client device 109 with the management service 120. In some cases, this can be part of an operating system setup process or out-of-box experience of the main operating system 164.. . . “) without manual user input at the computing device (see Fig. 3, ¶ [0058] “. . . In step 309, the management agent 147 can transmit provisioning telemetry data to the management service 120. The provisioning telemetry data can include information relevant to the provisioning of the client device 109. For example, the provisioning telemetry data can include a client device model identification, a manufacturer boot environment identification, a main operating system identification, a management application identification, a total provisioning time, and a provisioning result identification. The model identification of the client device 109 can include a model number assigned by the manufacturer, a unique device identifier of the client device 109 assigned by the management service 120, and other identifications. The manufacturer boot environment identification can include a product name and a version of the manufacturer boot environment 165. The main operating system identification can include a product name and a version of the main operating system 164. The total provisioning time can include a duration from a last boot time to the completion of the installation of the management application 149. Alternatively, the total provisioning time can refer to a duration from execution of the management agent 147 to the completion of the installation of the management application 149. The provisioning result identification can identify whether provisioning was successful or unsuccessful, for example, whether the management application 149 was successfully installed, or if the installation failed. ;
a username with which the operating system is to be automatically registered at the first user power-on without user interaction (see ¶ [0062] “ . . . The enrollment process 402 describes how the management application 149 can enroll the client device 109 with the management service 120. An out-of-box-experience of the main operating system 164 can include a simple guided user interface to setup the main operating system 164. The enrollment process 402 can be performed during an out-of-box experience of the client device 109, or immediately thereafter. For example, the out-of-box experience can be modified to include the enrollment process 402, or the enrollment process 409 can begin thereafter. In some examples, a user interface can be displayed during the enrollment process 409, which can notify a user of a status of the enrollment process. User inputs including a personal identification number (PIN), a username and password, or other credentials can be obtained. In other examples, the enrollment process 402 can be completed automatically, without user input. . . .”); and
a security token (e.g. enrollment token) as a single-use password with which the operating system is to be automatically registered at the first user power-on without the user interaction (see ¶ [0025] “ . . . Enrollment data 161 can include information for enrollment of a client device 109 with the management service 120. The enrollment data 161 can include an enrollment token like a character string, value, parameter, or file that can be used to authenticate the client device 109 with the management service 120. In some cases, the management service 120 can provide enrollment tokens corresponding to each of the client devices 109 and/or users that have a user account with the enterprise. To this end, a request for an enrollment token can be required to include a device identifier, username, password, or other information. An enrollment token can be valid during a certain time period after which the enrollment token can expire. . . .”);
responsively causing the computing device to store the previously user-provided configuration information (see ¶ [0035] “ . . . The management application 149 can be a management component 146 that can execute from the main operating system 164. The management application 149 can perform actions on the client device 109. For instance, the management application 149 can enroll the client device 109 with the management service 120. The management application 149 can transmit an enrollment request to an enrollment endpoint of the management service 120. The enrollment request can include an enrollment token and a device identifier of the client device 109. The management application 149 can receive and install an enrollment policy 131 to complete enrollment. The enrollment policy 131 can be transmitted from the management service 120 to the client device 109. The management application 149 can perform enrollment during the out of box experience (DOBE) or startup configuration process of the main operating system 164 . . .”) , the username, and the security token that have been retrieved from the server on a secure storage device of the computing device (see ¶ [0028] “ . .. The client device 109 can include a data store 163. The data store 163 can represent memory devices including, for example, random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, USB flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape or other memory components. The data store 163 can include a main operating system 164, a manufacturer boot environment 165, management components 146, boot variables 157, policies 131, enrollment data 161, client applications, and other data . . .”).; and
performing power-down of the computing device (see ¶ [0059] “ . .. In step 312, the management agent 147 can set provisioning variables. If the management application 149 was successfully installed, the management agent 147 can set the provisioning status variable to indicate that the client device 109 is provisioned for management by the management service 120 . . .”) and providing the computing device to the user (e.g. enrolling the device) (see ¶ [0066] “ . . . the management application 149 can enroll the client device with the management service. The management application 149 can install the enrollment policy to complete the enrollment of the client device 109 with the management service 120. . . “) .
Polyakov fails to explicitly teach but Reagan teaches at first power on (see Col 5: Lines 32-39 “ . . . should a client device 106 that has been powered on in a factory reset condition, or with no user data or device profile data provisioned upon the client device 106, the client device 106 can communicate with the device discovery computing environment 109 in order to discover the network address of a registration server 121 with which it should communicate in order to enroll itself with a management system 119. . . “).
The motivation to combine Reagan with Polyakov is described for the rejection of claim 1 and is incorporated herein.
The combination of Polyakov and Reagan fails to explicitly teach,
However Balakrishnan teaches previously user-provided configuration information in accordance with which an operating system of the computing device is to be automatically configured (see Balakrishnan ¶ [0007]” . . . configuring a plurality of baseboard management controllers (BMCs) installed on a plurality of clusters of managed devices. . . ; see ¶ [0008]” . . . allow a user to provide one set of BMC configuration information to each of the plurality of clusters of managed devices; a master BMC configuration database configured to store the set of BMC configuration information for each of the plurality of clusters of managed devices received from the plurality of input interfaces; a plurality of output interfaces configured to communicate with each master managed device of each cluster of managed devices; and a master BMC configuration module constructed to configure the BMCs installed on each master managed device of each cluster through the plurality of output interfaces. . . .” see ¶¶ [0056-0063]” . . . The initial information received from the user includes: the number of clusters, the number of managed devices in each of these clusters, the IP address of all managed devices (including one master managed device and one or more slave managed devices in various clusters networked with the synchronous BMC configuration system 100, and initial BMC configuration information for each of the BMC on the master managed devices for each cluster. The BMC is configured to perform one or more of following platform management functions: Remote access to the BMC through the system's serial port and integrated network interface card (NIC) Fault logging and Simple Network Management Protocol (SNMP) alerting through Platform Event Filters (PEFs) Access to the system event log (SEL) and access to sensor status information Control of system functions, including power-up and power-down Support that is independent of the system's power up operating state Text console redirection for system setup, text based utilities, and operating system (OS) consoles . . .”; see ¶ [0089] “ . . . the master BMC configuration module 240 includes: (a) a communication interface 241, and (b) a discovery module 242. The communication interface 241 facilitates the communication from the user through the set of input interfaces, and to the master and slave managed devices of each cluster of managed devices. The discovery module 242 of the master BMC configuration module 240 is used to discover all master managed devices of each cluster of managed devices based on the BMC configuration information received from the user and/or retrieved from the master BMC configuration database 250, such as the number of clusters, the number of slave managed devices in each cluster of managed devices, the IP addresses of the master and slave managed devices of each cluster of managed devices . . . “ ) .
The motivation to combine Balakrishnan with the combination of Polyakov and Reagan is described for the rejection of claim 1 and is incorporated herein.
In regard to claim 10, the combination of Polyakov, Reagan, and Balakrishnan teaches wherein the computing device is caused to retrieve, from the server, the previously user-provided configuration information, the username, and the security token via the computing device (see Reagan Col 4: Lines 58-61 as described for the rejection of claim 6 and incorporated herein) automatically executing instructions upon the power-on of the computing device (see Reagan Col 6: Lines 42 – 62 as described for the rejection of claim 4 and incorporated herein).
The motivation to combine Reagan with Polyakov and Balakrishnan is described for the rejection of claims 1,4, and 6 and is incorporated herein.
In regard to claim 11, the combination of Polyakov, Reagan and Balakrishnan teaches wherein the computing device is responsively caused to store the previously user-provided configuration information (see Polykov ¶ [0057] as described for the rejection of claim 3 and incorporated herein), the username, and the security token that have been retrieved from the server on the secure storage device via the computing device (see Reagan Col 4: Lines 58-61 as described for the rejection of claim 6 and incorporated herein) automatically executing instructions upon the power-on of the computing device (see Reagan Col 6: Lines 42 – 62 as described for the rejection of claim 4 and incorporated herein).
The motivation to combine Reagan with Polyakov and Balakrishnan is described for the rejection of claim 1, 4, and 6 and is incorporated herein.
In regard to claim 12, the combination of Polyakov and Reagan teaches wherein the computing device stores the previously user-provided configuration information, the username, and the security token that have been retrieved from the server on the secure storage device via a management instrumentation service provided by the operating system (see Polyakov ¶¶ [0021-0023] as described for the rejection of claim 7 and incorporated herein).
In regard to claim 14, Polyakov teaches A non-transitory computer-readable data storage medium storing program instructions executable by a processor to perform processing (see ¶ [0078] “ . .. any logic or application described that includes software or code can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system such as a processor in a computer system or other system. In this sense, the logic can include, for example, statements including instructions and declarations that can be fetched from the computer-readable medium and executed by the instruction execution system. In the context of the present disclosure, a “computer-readable medium” can be any medium that can contain, store, or maintain the logic or application described for use by or in connection with the instruction execution system. . . “) comprising:
prior to providing a computing device to a user (see ¶ [0022] “ . . . An enterprise can operate the management service 120 to oversee or manage the provisioning and operation of the client devices 109. The management service 120 can remotely configure the client device 109 by interacting with a management application 149 or another client application executed on the client device 109. The management service 120 can transmit various software components, including the current version of the management components 146, to the client device 109. These can be installed or configured by the manufacturer boot environment 165 . . policies 131 can require certain hardware or software functions of the client device 109 to be enabled or disabled during a certain time period or when the client device 109 is physically located at a particular location. . . .” (e.g. factory location) . . “), prompting the user for, and responsively receiving from the user, configuration information in accordance with which an operating system of the computing device is to be automatically configured at ((e.g. out-of-box experience) (see ¶ [0045] “ . . . The management application 149 can enroll the client device 109 with the management service 120. In some cases, this can be part of an operating system setup process or out-of-box experience of the main operating system 164.. . . “) without manual user input at the computing device (see Fig. 3, ¶¶ [0058-0059] “ . . In step 309, the management agent 147 can transmit provisioning telemetry data to the management service 120. The provisioning telemetry data can include information relevant to the provisioning of the client device 109. For example, the provisioning telemetry data can include a client device model identification, a manufacturer boot environment identification, a main operating system identification, a management application identification, a total provisioning time, and a provisioning result identification. The model identification of the client device 109 can include a model number assigned by the manufacturer, a unique device identifier of the client device 109 assigned by the management service 120, and other identifications. The manufacturer boot environment identification can include a product name and a version of the manufacturer boot environment 165. The main operating system identification can include a product name and a version of the main operating system 164. The total provisioning time can include a duration from a last boot time to the completion of the installation of the management application 149. Alternatively, the total provisioning time can refer to a duration from execution of the management agent 147 to the completion of the installation of the management application 149. The provisioning result identification can identify whether provisioning was successful or unsuccessful, for example, whether the management application 149 was successfully installed, or if the installation failed. In step 312, the management agent 147 can set provisioning variables. If the management application 149 was successfully installed, the management agent 147 can set the provisioning status variable to indicate that the client device 109 is provisioned for management by the management service 120 . . .”) ;
prior to providing the computing device to the user, prompting the user for ((e.g. out-of-box experience) (see ¶ [0045] “ . . . The management application 149 can enroll the client device 109 with the management service 120. In some cases, this can be part of an operating system setup process or out-of-box experience of the main operating system 164.. . . “), and responsively receiving from the user, a username with which the operating system is to be automatically registered at the first user power-on of the computing device without user interaction (see ¶ [0062] “ . . . The enrollment process 402 describes how the management application 149 can enroll the client device 109 with the management service 120. An out-of-box-experience of the main operating system 164 can include a simple guided user interface to setup the main operating system 164. The enrollment process 402 can be performed during an out-of-box experience of the client device 109, or immediately thereafter. For example, the out-of-box experience can be modified to include the enrollment process 402, or the enrollment process 409 can begin thereafter. In some examples, a user interface can be displayed during the enrollment process 409, which can notify a user of a status of the enrollment process. User inputs including a personal identification number (PIN), a username and password, or other credentials can be obtained. In other examples, the enrollment process 402 can be completed automatically, without user input. . . .”);
generating a security token (e.g. enrollment token) as a single-use password with which the operating system is to be automatically registered at the first user power-on of the computing device without user interaction (see ¶ [0025] “ . . . Enrollment data 161 can include information for enrollment of a client device 109 with the management service 120. The enrollment data 161 can include an enrollment token like a character string, value, parameter, or file that can be used to authenticate the client device 109 with the management service 120. In some cases, the management service 120 can provide enrollment tokens corresponding to each of the client devices 109 and/or users that have a user account with the enterprise. To this end, a request for an enrollment token can be required to include a device identifier, username, password, or other information. An enrollment token can be valid during a certain time period after which the enrollment token can expire. . . .”) ;
storing the configuration information, the username, and the security token on a server (see Fig. 1 management system 103) (see ¶ [0012] “ . . . The management system 103 can include a server computer or any other system providing computing capability. . . .”; see ¶¶ [0013-0014]” . . . The management system 103 can execute a management service 120 to oversee management of the client devices 109. The components executed on the management system 103 can include the management service 120, as well as other applications, services, processes, systems, engines or functionality not discussed in detail. An enterprise, such as one or more companies or other organizations, can operate the management service 120 to oversee or manage the operation of the client devices 109 of its employees, contractors, customers, students or other users having user accounts with the enterprise. An enterprise can include any customer of the management service 120. The management service 120 can have a command queue storing an action to perform on a particular client device 109 upon check-in of the client device 109 . . .” see ¶ [0028] “ . . The client device 109 can include a data store 163. The data store 163 can represent memory devices including, for example, random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, USB flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape or other memory components. The data store 163 can include a main operating system 164, a manufacturer boot environment 165, management components 146, boot variables 157, policies 131, enrollment data 161, client applications, and other data . . .”)
sending the security token to the username for entry by the user after configuration and registration of the operating system at the first user power-on of the computing device (see ¶ [0035] “ . . . The management application 149 can be a management component 146 that can execute from the main operating system 164. The management application 149 can perform actions on the client device 109. For instance, the management application 149 can enroll the client device 109 with the management service 120. The management application 149 can transmit an enrollment request to an enrollment endpoint of the management service 120. The enrollment request can include an enrollment token and a device identifier of the client device 109. The management application 149 can receive and install an enrollment policy 131 to complete enrollment. The enrollment policy 131 can be transmitted from the management service 120 to the client device 109. The management application 149 can perform enrollment during the out of box experience (DOBE) or startup configuration process of the main operating system 164 . . .”).
Polyakov fails to explicitly teach but Reagan teaches at first power on (see Col 5: Lines 32-39 “ . . . should a client device 106 that has been powered on in a factory reset condition, or with no user data or device profile data provisioned upon the client device 106, the client device 106 can communicate with the device discovery computing environment 109 in order to discover the network address of a registration server 121 with which it should communicate in order to enroll itself with a management system 119. . . “).
The motivation to combine Reagan with Polyakov is described for the rejection of claim 1 and is incorporated herein.
The combination of Polyakov and Reagan fails to explicitly teach
However Balakrishnan teaches(see Balakrishnan ¶ [0007]” . . . configuring a plurality of baseboard management controllers (BMCs) installed on a plurality of clusters of managed devices. . . ; see ¶ [0008]” . . . allow a user to provide one set of BMC configuration information to each of the plurality of clusters of managed devices; a master BMC configuration database configured to store the set of BMC configuration information for each of the plurality of clusters of managed devices received from the plurality of input interfaces; a plurality of output interfaces configured to communicate with each master managed device of each cluster of managed devices; and a master BMC configuration module constructed to configure the BMCs installed on each master managed device of each cluster through the plurality of output interfaces. . . .” see ¶¶ [0056-0063]” . . . The initial information received from the user includes: the number of clusters, the number of managed devices in each of these clusters, the IP address of all managed devices (including one master managed device and one or more slave managed devices in various clusters networked with the synchronous BMC configuration system 100, and initial BMC configuration information for each of the BMC on the master managed devices for each cluster. The BMC is configured to perform one or more of following platform management functions: Remote access to the BMC through the system's serial port and integrated network interface card (NIC) Fault logging and Simple Network Management Protocol (SNMP) alerting through Platform Event Filters (PEFs) Access to the system event log (SEL) and access to sensor status information Control of system functions, including power-up and power-down Support that is independent of the system's power up operating state Text console redirection for system setup, text based utilities, and operating system (OS) consoles . . .”; see ¶ [0089] “ . . . the master BMC configuration module 240 includes: (a) a communication interface 241, and (b) a discovery module 242. The communication interface 241 facilitates the communication from the user through the set of input interfaces, and to the master and slave managed devices of each cluster of managed devices. The discovery module 242 of the master BMC configuration module 240 is used to discover all master managed devices of each cluster of managed devices based on the BMC configuration information received from the user and/or retrieved from the master BMC configuration database 250, such as the number of clusters, the number of slave managed devices in each cluster of managed devices, the IP addresses of the master and slave managed devices of each cluster of managed devices . . . “ ).
The motivation to combine Balakrishnan with the combination of Polyakov and Reagan is described for the rejection of claim 1 and is incorporated herein.
Claim 5 is rejected under 35 U.S.C. 103 as being un-patentable over Polyakov et al. (U.S. 2020/0387385 A1; herein referred to as Polykov) in view of Reagan et al. (U.S. 10,445,082 B2; herein referred to as Reagan) in further view of Balakrishnan et al. (U.S. 2015/0178095 A1; herein referred to as Balakrishnan) as applied to claims 1 – 4, 6 – 7, 9 – 12, and 14 in further view of Griffin (U.S. 2013/0040729 A1; herein referred to as Griffin).
In regard to claim 5, the combination of Polyakov, Reagan, and Balakrishnan teaches wherein at completion of automatic configuration and registration of the operating system (see Polyakov ¶ [0066] “ . . . the management application 149 can enroll the client device with the management service. The management application 149 can install the enrollment policy to complete the enrollment of the client device 109 with the management service 120. . . “),
The combination of Polyakov, Reagan, and Balakrishnan fails to expclitly teach but Griffin teaches the operating system is to:
present a login screen at which a user is to enter the username and an operating system password (see Griffin Fig. 5, ¶ [0079]” . . . FIG. 5 is a screen shot showing one embodiment of an interface screen 1010 that may be shown to a user to confirm initiate of the account set-up process initiated at screen 1000. The screen 1010 includes a confirmation field 1012. The confirmation field 1012 indicates to the user that an e-mail has been sent to the user's account and that the set-up process can continue after the user receives the e-mail and selects a link included in the e-mail. The steps of sending an e-mail to the user and holding the account set-up process until the user selects a link in the e-mail are optional and may be used to authenticate the user. FIG. 6 is a screen shot showing one embodiment of an interface screen 1014 that may be shown to a user to receive log-in information. The screen 1014 may have a log-in information field 1016 for receiving a user's log-in identifier (e.g., a username and/or e-mail address) as well as a password. Upon entering the information requested at the log-in information field 1016, the user may initiate log-in by selecting the log-in button 1018... . . .”) ; and
responsive to user entry of the username and of the security token as the operating system password, prompt the user to change the operating system password (Fig. 9, ¶ [0079] “ . . . The screen 1014 may be shown to a user upon selection of the button 1006 from screens 1000 or 1010. In some example embodiments, the screen 1014 may also be shown to a user when the user selects the link included in the e-mail described above with respect to the screen 1010. In this case, the password requested by field 1016 may also be provided by the e-mail. A password sent to the user via the e-mail may be temporary and the user may be prompted to change the password upon log-in, for example, via screen 1030 shown in FIG. 9. . . “).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s application to incorporate systems, devices, and methods directed to a gaming management system for determining the configuration data to computer operating system standards and enabling changes to the configuration to be made, as taught by Griffin, into systems, devices, and methods directed to persistent device provisioning, where a management agent is executed from the manufacturer boot environment, and the management agent determines that a main operating system of the client device is currently un-provisioned for management by the management service, so that the management agent installs a management application that is executable in the main operating system, and the client device boots to the main operating system and executes the management application so that the management application enrolls the client device with the management service by installing an enrollment token received from the management service, and upon detection of a triggering event, detection of whether the management agent application is installed so that the agent application can then complete an enrollment of the device with a management system, where certain components of such a process can be bundled with the device operating system or as a system application, and user provided configurations that are stored on a central management system and retrieved when necessary to go online as taught by the combination of Polyakov, Reagan, and Balakrishnan. Such incorporation enables the user to change the password when the computer device is received from the factory.
Claim 8 is rejected under 35 U.S.C. 103 as being un-patentable over Polyakov et al. (U.S. 2020/0387385 A1; herein referred to as Polykov) in view of Reagan et al. (U.S. 10,445,082 B2; herein referred to as Reagan) in further view of Balakrishnan et al. (U.S. 2015/0178095 A1; herein referred to as Balakrishnan) as applied to claims 1 – 4, 6 – 7, 9 – 12, and 14 in further view of Liu et al. (U.S. 2019/0339988 A1; herein referred to as Liu).
In regard to claim 8, the combination of Polyakov, Reagan, and Balakrishnan fails to explicitly teach but Liu teaches wherein the secure storage device comprises an endpoint storage controller (see Liu ¶ [0005] “ . . . an Information Handling System (IHS) includes a storage controller; a processing system that is coupled to the storage controller; and a memory system that is coupled to the processing system and that includes instructions that, when executed by the processing system, cause the processing system to provide an Universally Extensible Firmware Interface (UEFI) engine that is configured to: create a device placeholder boot option that includes a device path terminating at a storage controller; move, during a first boot and based on first boot instructions, the device placeholder boot option to a desired location within a boot sequence; provide, during a second boot that is subsequent to the first boot and based on second boot instructions, an operating system on a storage system that is coupled to the storage controller; and replace, at the desired location within the boot sequence, the device placeholder boot option with an operating system boot option that was provided on the storage system in response to the provisioning of the operating system. . . .”).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s application to incorporate systems, devices, and methods directed to a pre-boot execution environment system coupled to a server device through a network, where the server device creates a device placeholder boot option including a device path terminating at a storage controller in the server device, as taught by Liu, into systems, devices, and methods directed to persistent device provisioning, where a management agent is executed from the manufacturer boot environment, and the management agent determines that a main operating system of the client device is currently un-provisioned for management by the management service, so that the management agent installs a management application that is executable in the main operating system, and the client device boots to the main operating system and executes the management application so that the management application enrolls the client device with the management service by installing an enrollment token received from the management service, and upon detection of a triggering event, detection of whether the management agent application is installed so that the agent application can then complete an enrollment of the device with a management system, where certain components of such a process can be bundled with the device operating system or as a system application, and user provided configurations that are stored on a central management system and retrieved when necessary to go online as taught by the combination of Polyakov, Reagan and Balakrishnan . Such incorporation enables an endpoint storage controller to be used to enter and restore configurations to an operating system of a computing device.
Claims 13 and 15 are rejected under 35 U.S.C. 103 as being un-patentable over Polyakov et al. (U.S. 2020/0387385 A1; herein referred to as Polykov) in view of Reagan et al. (U.S. 10,445,082 B2; herein referred to as Reagan) in further view of Balakrishnan et al. (U.S. 2015/0178095 A1; herein referred to as Balakrishnan) as applied to claims 1 – 4, 6 – 7, 9 – 12, and 14 in further view of Ryu et al. (U.S. 2004/0103042 A1; herein referred to as Ryu).
In regard to claim 13, the combination of Polyakov, Reagan, and Balakrishnan fails to explicitly teach but Ryu teaches wherein the computing device is initially assigned to the user incident to a procurement process initiated by the user in relation to the computing device (see Ryu ¶ [0048] “ . . . Productizing categories enables the user to make a product request, such as a notebook computer, and route it to an expert in the computer field within the organization. The request is automatically routed to the appropriate expert to review the request and add further specifications. This saves the organization money by purchasing a computer that meets the individual's needs and saves the requestor's time associated with finding the expert. Each participant in the procurement process may define and redefine the product request to make the request more specific as it is routed through the procurement system. At each step, each person processing the request can modify and better define the product request as needed. For example, the computer expert may convert the request for a notebook computer to an Intel Pentium III 850 Mhz product. The organization's buyer may convert it again to a specific product, such as an IBM notebook 2648R1U to order with a vendor. . . “).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s application to incorporate systems, devices, and methods directed to electronic procurement systems, particularly to such systems having the ability to process every expense item in an electronic catalog, as taught by Ryu, into systems, devices, and methods directed to persistent device provisioning, where a management agent is executed from the manufacturer boot environment, and the management agent determines that a main operating system of the client device is currently un-provisioned for management by the management service, so that the management agent installs a management application that is executable in the main operating system, and the client device boots to the main operating system and executes the management application so that the management application enrolls the client device with the management service by installing an enrollment token received from the management service, and upon detection of a triggering event, detection of whether the management agent application is installed so that the agent application can then complete an enrollment of the device with a management system, where certain components of such a process can be bundled with the device operating system or as a system application, and user provided configurations that are stored on a central management system and retrieved when necessary to go online as taught by the combination of Polyakov, Reagan, and Balakrishnan. Such incorporation enables a procurement system to be used to purchase the computing device to be configured.
In regard to claim 15, the combination of Polyakov, Reagan, Balakrishnan and Ryu teaches wherein the user is prompted for the configuration information incident to a procurement process initiated by the user (see Ryu ¶ [0052] “ . . . FIG. 2 illustrates a preferred embodiment of a user interface display screen for applying the invention to a catalog. The administrator begins by selecting the category to be tailored to the requirements of the organization. In the following example, the administrator selects the OFFICE SUPPLIES category to begin the productizing process and is directed to the next user interface display screen (FIG. 3a), where he is prompted to set the productizing rules. FIG. 3a illustrates Rule 1 of the productizing categories process. Rule 1 gives the administrator the option to either "show" or "don't show" the OFFICE SUPPLIES category and its descendent categories. If the administrator chooses "don't show," as is illustrated in FIG. 3a, the OFFICE SUPPLIES category will not be viewable by the intended users of the catalog and they will not be able to purchase any products from the OFFICE SUPPLIES category . . .”) in relation to the computing device (see Ryu ¶ [0048] as described for the rejection of claim 13 and is incorporated herein).
The motivation to combine Ryu with the combination of Polyakov, Reagan, and Balakrishnan is described for the rejection of claim 13 and is incorporated herein.
Claims 16 – 17 are rejected under 35 U.S.C. 103 as being un-patentable over Polyakov et al. (U.S. 2020/0387385 A1; herein referred to as Polykov) in view of Reagan et al. (U.S. 10,445,082 B2; herein referred to as Reagan) in further view of Balakrishnan et al. (U.S. 2015/0178095 A1; herein referred to as Balakrishnan) as applied to claims 1 – 4, 6 – 7, 9 – 12, and 14 in further view of Moore et al. (U.S. 2011/0179372 A1; herein referred to as Moore).
In regard to claim 16, the combination of Polykov, Reagan, and Balakrishnan fails to explicitly teach, wherein the previously user-provided configuration information comprises at least one of: a geographic region in which a user is using an existing computing device, a language in which the existing computing device is used, or a keyboard layout of the existing computing device (see Moore ¶ [0008] “ . . . a method is provided to automatically determine a keyboard layout and configure the keyboard accordingly, including without user intervention. Language and location information are obtained from a plurality of hardware and software sources. The hardware and software sources are prioritized based on the reliability of the language and location information provided by the respective source. The language and location information from the source with the highest priority is mapped to a keyboard layout of a hardware and/or an on-screen keyboard. The keyboard layout is used in multiple ways. For example, in some embodiments, the keyboard layout is used to configure a hardware keyboard to reflect an entry language and keyboard format that a user is likely to prefer based on the language and location information provided by the plurality of hardware and software sources. This enables the device to interpret key input signals from the hardware keyboard based on the determined keyboard layout without any need for the user to input keyboard configuration information in a separate keyboard configuration process . . .”).
It would have been obvious to one with ordinary skill in the art before the effective filing date of the applicant’s application to incorporate systems, devices, and methods directed to keyboard setup of a device without user intervention using language information and the geographical location of the device, as taught by Moore, into systems, devices, and methods directed to persistent device provisioning, where a management agent is executed from the manufacturer boot environment, and the management agent determines that a main operating system of the client device is currently un-provisioned for management by the management service, so that the management agent installs a management application that is executable in the main operating system, and the client device boots to the main operating system and executes the management application so that the management application enrolls the client device with the management service by installing an enrollment token received from the management service, and upon detection of a triggering event, detection of whether the management agent application is installed so that the agent application can then complete an enrollment of the device with a management system, where certain components of such a process can be bundled with the device operating system or as a system application, and user provided configurations that are stored on a central management system and retrieved when necessary to go online as taught by the combination of Polyakov, Reagan, and Balakrishnan. Such incorporation provides that important configuration information such as language of user and location of device is stored.
In regard to claim 17, the combination of Polyakov, Reagan, Balakrishnan, and Moore teaches wherein the computing device and the existing computing device are different devices (see Reagan Col 5: Lines 3 – 39 “ . . . The device discovery computing environment 109 may comprise, for example, a server computer or any other system providing computing capabilities. Alternatively, the device discovery computing environment 109 may employ multiple computing devices that may be arranged, for example, in one or more server banks, computer banks, or other arrangements. Such computing devices may be located in a single installation or may be distributed among many different geographical locations. For example, the device discovery computing environment 109 may include multiple computing devices that together form a hosted computing resource, a grid computing resource, and/or any other distributed computing arrangement. In some cases, the device discovery computing environment 109 may operate as at least a portion of an elastic computing resource where the allotted capacity of processing, network, storage, or other computing-related resources may vary over time. The device discovery computing environment 109 may also include or be operated as one or more virtualized computer instances that are executed in order to perform the functionality that is described herein. The device discovery computing environment 109 may be operated by an entity that is a third party relative to an operator of management computing environment 103. For example, an OEM may operate the device discovery computing environment 109 in order to direct a newly provisioned client device 106 to the appropriate address for the registration server 121 and/or management system 119 for enrollment with the management system 119. In other words, should a client device 106 that has been powered on in a factory reset condition, or with no user data or device profile data provisioned upon the client device 106, the client device 106 can communicate with the device discovery computing environment 109 in order to discover the network address of a registration server 121 with which it should communicate in order to enroll itself with a management system 119. . . .”).
The motivation to combine the references is described for the rejection of claim 1 and claim 16 and is incorporated herein. Additionally, Reagan describes the setup a new device from the configuration of a user’s pre-existing devices.
Conclusion
There are prior art made of record which are not relied upon but are considered pertinent to applicant’s disclosure. They are listed on the PTO-892 accompanying this action
Applicant's amendment (e.g. adding claims 16 and 17) 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 JAMES N FIORILLO whose telephone number is (571)272-9909. The examiner can normally be reached on 7:30 - 5 PM Mon - Fri..
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, John A. Follansbee can be reached on 571-272-3964. 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 the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/JAMES N FIORILLO/Examiner, Art Unit 2444
Prosecution Insights