Prosecution Insights
Last updated: April 19, 2026
Application No. 18/483,033

SHARED DEVICE FIRMWARE UPDATE

Non-Final OA §103
Filed
Oct 09, 2023
Examiner
LEE, MARINA
Art Unit
2192
Tech Center
2100 — Computer Architecture & Software
Assignee
DELL PRODUCTS, L.P.
OA Round
1 (Non-Final)
85%
Grant Probability
Favorable
1-2
OA Rounds
2y 9m
To Grant
99%
With Interview

Examiner Intelligence

Grants 85% — above average
85%
Career Allow Rate
551 granted / 646 resolved
+30.3% vs TC avg
Strong +19% interview lift
Without
With
+18.6%
Interview Lift
resolved cases with interview
Typical timeline
2y 9m
Avg Prosecution
12 currently pending
Career history
658
Total Applications
across all art units

Statute-Specific Performance

§101
13.1%
-26.9% vs TC avg
§103
44.5%
+4.5% vs TC avg
§102
19.1%
-20.9% vs TC avg
§112
12.9%
-27.1% vs TC avg
Black line = Tech Center average estimate • Based on career data from 646 resolved cases

Office Action

§103
DETAILED ACTION Notice of Pre-AIA or AIA Status The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This action is responsive to the application filed October 09, 2023. Claims 1-20 are pending and are presenting for examination. Examiner Notes Examiner cites particular columns and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirety as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner. 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. Claim Objections Claims 4 and 9 objected to because of the following informalities: As to claim 4 (lines 1-2), recite to include the limitation “the management service” appears lacking antecedent basis for this limitation in the claims and should be changed to, for example, -- the cloud-based management service -- instead. Appropriate correction is required. As to claim 9 (lines 4-5), recite to include the limitation “the management service” appears lacking antecedent basis for this limitation in the claims and should be changed to, for example, -- the cloud-based management service -- instead. Appropriate correction is required. Claim Rejections - 35 USC § 103 The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action: A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made. Claims 1 and 3-8 are rejected under 35 U.S.C. 103 as being unpatentable over Bedekar et al. (US 20210133689 A1, hereinafter Bedekar) in view of Viswanath et al. (US 20180181238 A1, hereinafter Viswanath). As to claim 1, Bedekar discloses a method comprising: connecting a user device to a plurality of shared peripheral devices in a conference room or shared workspace— (e.g., the managed rooms backbone 102 may execute on the conference room device 110 and monitor communications between various peripherals within a conference room 112. The conference room device 110 may be a special purpose device with custom hardware and/or software components, as well as a desktop computer, a laptop computer, a tablet computer, a smart phone, and a wearable computing device with custom components among other similar devices. The conference room device 110 may, for example, manage peripheral devices 114, 116, 118, 120, 122, 124, 126, and 128. The peripherals 114-128 may be collocated within a same conference room or shared space—see at least 0027-0028, FIG. 1, and associated text), wherein the shared peripheral devices are not configured for connection to any network – (e.g., -- conference room device 110 is not configuring or managing any of the peripheral device 114-128 yet as such “The conference room device 110 may monitor and manage meeting functionality as enabled by each of the peripheral devices 114-128. For example, the conference room device 110 may provide a user interface to access or initiate a meeting and manage meeting features such as audio/video controls, presentations, recordings, and the like as enabled by the peripheral devices 114-128. The conference room device 110 may communicate with the peripheral devices 114-128 via short range wireless communication such as include near field communication (NFC), Bluetooth communication, personal area network (PAN) communication, optical communication, and the like. The conference room device 110 may also communicate with the peripheral devices 114-128 via wired communications, for example, universal serial bus (USB) or similar connections – see at least 0027-0028, Fig. 1, and associated text); establishing a network connection with a cloud-based management service – (e.g., the managed rooms backbone 102 may monitor hardware signals from each peripheral device 114-128. In addition to hardware signals associated with each peripheral device, the managed rooms backbone 102 may also monitor operating system signals associated with the peripheral devices. Moreover, the managed rooms backbone 102 may capture signals from other applications executing on devices within the conference room or shared space. For example, data from other applications may include peripheral supplemental data and a telemetry heartbeat. The managed rooms backbone 102 may also query hardware signals that are specific to a particular device type. For example, application programming interfaces (APIs) from a particular hardware manufacturer may be queried to obtain a more specific error code or signal associated with the particular device. The managed from backbone 102 may combine this information and securely transmit the information across the network 108 to the management cloud 104. The combined data signals are generally referred to as room health data. – see at least 0034, Fig. 1, and associated text), wherein the management service is pre-populated with data regarding the plurality of shared peripheral devices and a plurality of conference rooms or shared workspaces that includes the conference room or shared workspace— (e.g., the management cloud 104 is illustrated as communicatively coupled with a single conference room 112. However, a management cloud according to the present techniques can manage any number of shared spaces across any number of organizations. Accordingly, a managed room system according to the present techniques can use aggregate telemetry to determine broader outages and report those to the users. For example, if all devices in a particular region exhibit connectivity issues, the present technique can inform users of the managed room system that there is a network outage for an entire whole region… the management cloud 104 may also transmit remediation tasks or strategies to a user. In some cases, a management services provider 106 may perform remote remediations of the conference room 112. Remote remediations may be executed automatically via remediation servers 134. – see at least 0034-0036, FIG. 1, and associated text). retrieving firmware version information from the plurality of shared peripheral devices— (e.g., a managed rooms backbone includes an application programming interface (API) that is to capture data signals, package the data signals and metadata, from each peripheral device 114-128 and upload the packaged data to a management cloud 104… The packaged signals and metadata may be referred to as room health data…the room health data may be compared to a manifest of expected values, such as expected firmware, expected installed updates, operating system versions, application versions, and basic input/output system (BIOS) versions. Accordingly, room health data may include such as expected firmware, expected installed updates, operating system versions, application versions, and basic input/output system (BIOS) versions, and the like. In embodiments, the signals are packaged in conjunction with system metadata…System metadata may include a location, and identification of the installed operating system, agent, and other key versions. In embodiments, the operating system version, key versions, etc. are taken from the conference room device. —see at least 0039--0045, 0056, FIG. 1, Fig. 2, FIG. 5, and associated text); transmitting the firmware version information to the cloud-based management service over the network connection – (e.g., the room health data may be received at the management cloud 104 via a communications broker/bus…the room health data may include such as expected firmware, expected installed updates, operating system versions, application versions, and basic input/output system (BIOS) versions –—see at least 0039--0045, 0056, 0061, FIG. 1, Fig. 2, FIG. 5, and associated text ; and transmitting location information to the cloud-based management service over the network connection –(e.g., the room health data may be received at the management cloud 104 via a communications broker/bus…the room health data may include such as expected firmware, expected installed updates, operating system versions, application versions, and basic input/output system (BIOS) versions. In embodiments, the signals are packaged in conjunction with system metadata…System metadata may include a location, and identification of the installed operating system, agent, and other key versions. In embodiments, the operating system version, key versions, etc. are taken from the conference room device. —see at least 0039--0045, 0056, FIG. 1, Fig. 2, FIG. 5, and associated text). It is to note that while Bedekar discloses transmitting location information to the cloud-based management service over the network connection (e.g., the room health data may be received at the management cloud 104 via a communications broker/bus…the room health data may include such as expected firmware as well as …System metadata may include a location, and identification of the installed operating system, agent, and other key versions…are taken from the conference room device) —see at least 0039--0045, 0056, FIG. 1, Fig. 2, FIG. 5, and associated text, but does not explicitly disclose; however, Viswanath, in an analogous art, discloses that the transmitting location information of the plurality of shared peripheral devices—(E.g., receive location from GPS of the user devices within the conference room as such “the environmental pertinence module 210 may determine that conference room Alpha of building Beta (or stored location coordinates associated with the same) is the likely location of the mobile device associated with such user at 3:07 PM PST. This likely location may be confirmed through location data received from the mobile device such as through received GPS coordinates or indications of WiFi access point detection associated with building Beta. In still other embodiments, this likely location may be confirmed by prompting the user of the device to input a location confirmation (e.g., a notification requesting that the user confirm they are in conference room Alpha of building Beta). With respect to receiving device location data at Block 304, in some embodiments, the mobile device (e.g., first mobile device 106 in FIG. 1) may transmit location data associated with the mobile device to the environmental pertinence server 102 at various intervals. In other embodiments, the mobile device may not transmit its location to the environmental pertinence server at various intervals, and may require that the environmental pertinence server 102 request the location of the mobile device. In some still further embodiments, the environmental pertinence server 102 and/or environmental pertinence module 210, may receive device location data related to a mobile device due to the docking or network access of the mobile device at a location (e.g., when a phone is docked at a computer or network access is obtained and the device location data is transmitted via a LAN).” – see at least 0086-0087, Fig. 1, Fig. 3, and associated text. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated Viswanath’s teaching into Bedekar ’s teaching for further improving user’s satisfaction in providing contents within user device’s location as seen in Viswanath (e.g., 0002-0003). As to claim 3, modified Bedekar with Viswanath discloses wherein connecting the user device to the plurality of shared peripheral devices includes establishing a wired universal serial bus (USB) connection from the user device to the plurality of shared peripheral devices – (E.g., the conference room device 110 may also communicate with the peripheral devices 114-128 via wired communications, for example, universal serial bus (USB) or similar connections.—see Bedekar, at least 0028, Fig. 1, and associated text). As to claim 4, it is to note that while Bedekar discloses transmitting location information to the cloud-based management service over the network connection (e.g., the room health data may be received at the management cloud 104 via a communications broker/bus…the room health data may include such as expected firmware as well as …System metadata may include a location, and identification of the installed operating system, agent, and other key versions…are taken from the conference room device) —see at least 0039--0045, 0056, FIG. 1, Fig. 2, FIG. 5, and associated text, but does not explicitly disclose; however, Viswanath, in an analogous art, discloses wherein transmitting location information to the management service includes identifying a name of the conference room or shared workspace – (E.g., receive location from GPS of the user devices within the conference room as well and conference room name (i.e., conference room Alpha of building Beta) as such “the environmental pertinence module 210 may determine that conference room Alpha of building Beta (or stored location coordinates associated with the same) is the likely location of the mobile device associated with such user at 3:07 PM PST. This likely location may be confirmed through location data received from the mobile device such as through received GPS coordinates or indications of WiFi access point detection associated with building Beta. In still other embodiments, this likely location may be confirmed by prompting the user of the device to input a location confirmation (e.g., a notification requesting that the user confirm they are in conference room Alpha of building Beta). With respect to receiving device location data at Block 304, in some embodiments, the mobile device (e.g., first mobile device 106 in FIG. 1) may transmit location data associated with the mobile device to the environmental pertinence server 102 at various intervals. In other embodiments, the mobile device may not transmit its location to the environmental pertinence server at various intervals, and may require that the environmental pertinence server 102 request the location of the mobile device. In some still further embodiments, the environmental pertinence server 102 and/or environmental pertinence module 210, may receive device location data related to a mobile device due to the docking or network access of the mobile device at a location (e.g., when a phone is docked at a computer or network access is obtained and the device location data is transmitted via a LAN).” – see at least 0086-0087, Fig. 1, Fig. 3, and associated text. Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated Viswanath’s teaching into Bedekar ’s teaching for further improving user’s satisfaction in providing contents within user device’s location as seen in Viswanath (e.g., 0002-0003). As to claim 5, it is to note that while Bedekar discloses transmitting location information to the cloud-based management service over the network connection (e.g., the room health data may be received at the management cloud 104 via a communications broker/bus…the room health data may include such as expected firmware as well as …System metadata may include a location, and identification of the installed operating system, agent, and other key versions…are taken from the conference room device) —see at least 0039--0045, 0056, FIG. 1, Fig. 2, FIG. 5, and associated text, but does not explicitly disclose; however, Viswanath, in an analogous art, discloses further comprising: gathering the location information from a first peripheral device of the plurality of peripheral devices –(E.g., receive location from GPS of the user devices within the conference room as well and conference room name (i.e., conference room Alpha of building Beta)—see Viswanath, at least 0086-0087, Fig. 1, Fig. 3, and associated text) ; or gathering the location information from a meeting calendar application -- (e.g., The environmental pertinence module 210 may use meeting time data and meeting location data extracted from scheduling data to determine a likely location of the mobile device. For example, if a user of the mobile device is scheduled to participate in a design review meeting in conference room Alpha of building Beta at 3:00 PM PST, the environmental pertinence module 210 may determine that conference room Alpha of building Beta (or stored location coordinates associated with the same) is the likely location of the mobile device associated with such user at 3:07 PM PST. – see Viswanath, at least 0086-0087, Fig. 1, Fig. 3, and associated text). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated Viswanath’s teaching into Bedekar ’s teaching for further improving user’s satisfaction in providing contents within user device’s location as seen in Viswanath (e.g., 0002-0003). As to claim 6, modified Bedekar with Viswanath discloses further comprising: receiving a remediation package from the cloud-based management service, wherein the remediation package is based at least in part upon the firmware version information and the location information; and applying the remediation package to a first peripheral device of the plurality of shared peripheral devices according to the remediation package—(e.g., in the event that the room health assessment indicates an issue or failure of components within the conference room receiving at the management cloud 104 via a communications broker/bus…the room health data may include such as expected firmware, expected installed updates, operating system versions, application versions, and basic input/output system (BIOS) versions. In embodiments, the signals are packaged in conjunction with system metadata…System metadata may include a location, and identification of the installed operating system, agent, and other key versions, the management cloud 104 may also transmit remediation tasks …remediations may include peripheral-specific tasks, such as updating drivers or firmware—see Bedekar, at least 0036-0037, 0039--0045, 0056, FIG. 1, Fig. 2, FIG. 5, and associated text). As to claim 7, modified Bedekar with Viswanath discloses wherein retrieving the firmware version information comprises: running an application on the user device, wherein the application is managed by an information technology (IT) administrator of the conference room or shared workspace, wherein the application is configured to poll the plurality of shared peripheral devices(e.g., a managed rooms backbone includes an application programming interface (API) that is to capture data signals, package the data signals and metadata, from each peripheral device 114-128 and upload the packaged data to a management cloud 104… The packaged signals and metadata may be referred to as room health data…the room health data may be compared to a manifest of expected values, such as expected firmware, expected installed updates, operating system versions, application versions, and basic input/output system (BIOS) versions. Accordingly, room health data may include such as expected firmware, expected installed updates, operating system versions, application versions, and basic input/output system (BIOS) versions, and the like. In embodiments, the signals are packaged in conjunction with system metadata…System metadata may include a location, and identification of the installed operating system, agent, and other key versions. In embodiments, the operating system version, key versions, etc. are taken from the conference room device. —see Bedekar, at least 0039--0045, 0056, FIG. 1, Fig. 2, FIG. 5, and associated text). As to claim 8, modified Bedekar with Viswanath discloses wherein the user device comprises a laptop or tablet computer under management by an information technology (IT) administrator of the conference room or shared workspace – (e.g., The conference room device 110 may be a special purpose device with custom hardware and/or software components, as well as a desktop computer, a laptop computer, a tablet computer, a smart phone, and a wearable computing device with custom components among other similar devices. The conference room device 110 may, for example, manage peripheral devices 114, 116, 118, 120, 122, 124, 126, and 128… In embodiments, the managed rooms backbone 102 may function as an interface between a user and each peripheral component—see Bedekar, at least 0028, Fig. 1, and associated text). It is to note that while modified Bedekar with Viswanath discloses wherein the user device comprises a laptop or tablet computer under management by the user of the conference room or shared workspace --see Bedekar, at least 0028, Fig. 1, and associated text; but the modified does not explicitly disclose that the user is an information technology (IT) administrator; however, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporate administrator into user ‘s role of modified teaching of Bedekar with Viswanath and still accomplish predictable results of managing of the conference room device 110 of managed rooms backbone 102 with each peripheral component regardless to the role of user’s device as seen in Bedekar (e.g.0028). Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Bedekar in view of Viswanath, and in further view of BEERSE et al. (US 20130279678 A1, hereinafter Beerse). As to claim 2, it is to note that while modified Bedekar with Viswanath discloses further comprising: participating in a networked conferencing session, using the user device— (e.g. a user of the mobile device participate in a design review meeting in conference room Alpha of building Beta at 3:00 PM PST – Viswanath, at least 0086) but does not explicitly disclose; however, Beerse, in analogous art, discloses that using the user device is in the conference room or shared workspace to participate in a networked conferencing session --(e.g., end user devise such as computing 110, 120, 130 can be, but are not limited to, a personal computer, a smart phone, and the like located in a meeting room is participating in the conference session within server 140 – see Beerse, at least 0025, 0043, 0059, Fig. 1, Fig. 2, and associated text). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated Beerse’ teaching into modified teaching of Bedekar with Viswanath and still accomplish predictable results of participating in online meeting regardless to the location of user’s device as seen in Beerse (e.g., 0025, 0043, 0059, Fig. 1, and associated text). Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Bedekar in view of Viswanath, and in further view of BEDEKAR et al. (US 20210405992 A1, hereinafter Bedekar1). As to claim 9, it is to note that while modified Bedekar with Viswanath discloses retrieving data from the plurality of shared peripheral devices; and transmitting the retrieved data to the management service over the network connection --(e.g., the managed rooms backbone 102 may monitor hardware signals from each peripheral device 114-128. In addition to hardware signals associated with each peripheral device, the managed rooms backbone 102 may also monitor operating system signals associated with the peripheral devices. Moreover, the managed rooms backbone 102 may capture signals from other applications executing on devices within the conference room or shared space. For example, data from other applications may include peripheral supplemental data and a telemetry heartbeat. The managed rooms backbone 102 may also query hardware signals that are specific to a particular device type. For example, application programming interfaces (APIs) from a particular hardware manufacturer may be queried to obtain a more specific error code or signal associated with the particular device. The managed from backbone 102 may combine this information and securely transmit the information across the network 108 to the management cloud 104. The combined data signals are generally referred to as room health data. – see Bedekar, at least 0034, Fig. 1, and associated text), but, the modified does not explicitly disclose; however, Bedekar1, in an analogous art, discloses that the retrieving data is unique identifiers and health status from the plurality of shared peripheral devices— (e.g., the managed rooms backbone 202 may manage and monitor one or more managed devices 210 physically located in a respective managed room 202 and determine each managed device (i.e. managed devices 114-128) of a plurality of managed device available in a shared space as well as determine the health data for each managed device-- see Bedekar1, at least 0027,0040, 0048-0050, Figs. 1-3, and associated text). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated Bedekar1’s teaching into modified teaching of Bedekar with Viswanath for further determining the root cause of failures within managed devices of the share space; accordingly, promoting effectiveness in maintenance within managed device of a shared space as seen in Bedekar1 (e.g., 0001-0003). 10. Claims 10, 12, and 13, and 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over Bedekar in view of TSUKADA (US 20190306031 A1). As to claim 10, Bedekar discloses an Information Handling System (IHS) --(e.g. computing device 702 – see at least 0063, Fig. 7, and associated text), comprising: one or more processors – (e.g., a processing unit 704– see at least 0063, Fig. 7, and associated text); and a memory coupled to the one or more processors, wherein the memory comprises computer-readable instructions, which upon execution by the one or more processors –see at least 0063-0065, Fig. 7, and associated text, causes the IHS to: analyze information regarding a plurality of conference rooms under management by a cloud-based management service—(e.g., the room health monitor 132 of the management cloud 104 may analyze and asses the obtained room health data from the peripheral device 114-128of the conference room 112 or other conference rooms – see at least 0017, 0027, 0035-0036, 0052, Figs. 1-3 and associated text), including identifying a first conference room having a plurality of peripheral devices, wherein a first peripheral device of the plurality of peripheral devices is identified as malfunctioning by the information regarding the plurality of conference rooms – (e.g., in the event that the room health assessment indicates an issue or failure of components within the conference room receiving at the management cloud 104 via a communications broker/bus…the room health data may include such as expected firmware, expected installed updates, operating system versions, application versions, and basic input/output system (BIOS) versions. In embodiments, the signals are packaged in conjunction with system metadata…System metadata may include a location, and identification of the installed operating system, agent, and other key versions, the management cloud 104 may also transmit remediation tasks …remediations may include peripheral-specific tasks, such as updating drivers or firmware—see Bedekar, at least 0036-0037, 0039--0045, 0056, FIG. 1, Fig. 2, FIG. 5, and associated text), and wherein the first peripheral device is not configured for network communication--(e.g., -- conference room device 110 is not configuring or managing any of the peripheral device 114-128 yet as such “The conference room device 110 may monitor and manage meeting functionality as enabled by each of the peripheral devices 114-128. For example, the conference room device 110 may provide a user interface to access or initiate a meeting and manage meeting features such as audio/video controls, presentations, recordings, and the like as enabled by the peripheral devices 114-128. The conference room device 110 may communicate with the peripheral devices 114-128 via short range wireless communication such as include near field communication (NFC), Bluetooth communication, personal area network (PAN) communication, optical communication, and the like. The conference room device 110 may also communicate with the peripheral devices 114-128 via wired communications, for example, universal serial bus (USB) or similar connections – see at least 0027-0028, Fig. 1, and associated text); and coordinate with the user to apply a remediation package to the first peripheral device, wherein applying the remediation package to the first peripheral device employs a physical presence of a user device, associated with the user, in the conference room – (E.g., In the event that the room health assessment indicates an issue or failure of components within the conference room, the management cloud 104 may transmit remediation tasks …remediations may include peripheral-specific tasks, such as updating drivers or firmware…the management cloud 104 may also transmit remediation tasks or strategies to a user… the user can be a member of the organization that controls or owns the corresponding shared space – see at least 0036-0037, 0039-0045, 0053, 0056. 0061, Figs. 1-3, Fig. 5, and associated text). It is to note that while Bedekar discloses that the management cloud 104 is monitoring and managing the peripheral devices 114-128 within the multiple conference rooms or shared spaces --see at least 0017, 0036-0037, 0039-0045, 0053, 0056. 0061, Figs. 1-3, Fig. 5, and associated text but does not explicitly disclose; however, TSUKADA, in an analogous art, discloses search a plurality of conference room bookings to determine an identity of a user who has booked the first conference room – (e.g., providing the reservation list screen 230 has a display area 231 for displaying a shared resource name (in this example, a name of place) and a display area 232 for displaying a date and time …and a user ID of a user who made a reservation. – see TSUKADA, at least 0196, Fig. 17, and associated text). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated TSUKADA’s teaching into Bedekar’s teaching for further alerting the user of issues within managed devices of the share space; accordingly, promoting effectiveness in maintenance within managed device of a shared space. As to claim 12, modified Bedekar with TSUKADA discloses wherein the remediation package includes instructions to apply a firmware update to the first peripheral device--(e.g., the management cloud 104 may also transmit remediation tasks …remediations may include peripheral-specific tasks, such as updating drivers or firmware—see Bedekar, at least 0036-0037, 0039--0045, 0056, FIG. 1, Fig. 2, FIG. 5, and associated text). As to claim 13, modified Bedekar with TSUKADA discloses wherein the remediation package includes an update patch or firmware update code and instructions to apply the update patch or firmware update code -- (e.g., the management cloud 104 may also transmit remediation tasks …remediations may include peripheral-specific tasks, such as updating drivers or firmware—see Bedekar, at least 0036-0037, 0039--0045, 0056, FIG. 1, Fig. 2, FIG. 5, and associated text). As to claim 17, Bedekar discloses a non-transitory computer-readable storage device – (E.g., computer-readable medium 608 -- see at least 0062, Fig. 6 and associated text) having instructions stored thereon for peripheral device remediation, wherein execution of the instructions by one or more processors of an IHS (Information Handling System) causes the one or more processors to: analyze information regarding a plurality of conference rooms under management by a cloud-based management service—(e.g., the room health monitor 132 of the management cloud 104 may analyze and asses the obtained room health data from the conference room 112 or other conference rooms – see at least 0017, 0027, 0035-0036, 0052, Figs. 1-3 and associated text ), including identifying a first conference room having a plurality of peripheral devices, wherein a first peripheral device of the plurality of peripheral devices is identified as malfunctioning in the information regarding the plurality of conference rooms– (e.g., in the event that the room health assessment indicates an issue or failure of components within the conference room receiving at the management cloud 104 via a communications broker/bus…the room health data may include such as expected firmware, expected installed updates, operating system versions, application versions, and basic input/output system (BIOS) versions. In embodiments, the signals are packaged in conjunction with system metadata…System metadata may include a location, and identification of the installed operating system, agent, and other key versions, the management cloud 104 may also transmit remediation tasks …remediations may include peripheral-specific tasks, such as updating drivers or firmware—see Bedekar, at least 0036-0037, 0039--0045, 0056, FIG. 1, Fig. 2, FIG. 5, and associated text), and wherein the first peripheral device is not configured for network communication-(e.g., -- conference room device 110 is not configuring or managing any of the peripheral device 114-128 yet as such “The conference room device 110 may monitor and manage meeting functionality as enabled by each of the peripheral devices 114-128. For example, the conference room device 110 may provide a user interface to access or initiate a meeting and manage meeting features such as audio/video controls, presentations, recordings, and the like as enabled by the peripheral devices 114-128. The conference room device 110 may communicate with the peripheral devices 114-128 via short range wireless communication such as include near field communication (NFC), Bluetooth communication, personal area network (PAN) communication, optical communication, and the like. The conference room device 110 may also communicate with the peripheral devices 114-128 via wired communications, for example, universal serial bus (USB) or similar connections – see at least 0027-0028, Fig. 1, and associated text); and coordinate with the user to apply a remediation package to the first peripheral device, wherein applying the remediation package to the first peripheral device employs a physical presence of a user device, associated with the user, in the conference room– (E.g., In the event that the room health assessment indicates an issue or failure of components within the conference room, the management cloud 104 may transmit remediation tasks …remediations may include peripheral-specific tasks, such as updating drivers or firmware…the management cloud 104 may also transmit remediation tasks or strategies to a user… the user can be a member of the organization that controls or owns the corresponding shared space – see at least 0036-0037, 0039-0045, 0053, 0056. 0061, Figs. 1-3, Fig. 5, and associated text). It is to note that while Bedekar discloses that the management cloud 104 is monitoring and managing the peripheral devices 114-128 within the multiple conference rooms or shared spaces --see at least 0017, 0036-0037, 0039-0045, 0053, 0056. 0061, Figs. 1-3, Fig. 5, and associated text but does not explicitly disclose; however, TSUKADA, in an analogous art, discloses search a plurality of conference room bookings to determine an identity of a user who has booked the first conference room -- (e.g., providing the reservation list screen 230 has a display area 231 for displaying a shared resource name (in this example, a name of place) and a display area 232 for displaying a date and time …and a user ID of a user who made a reservation. – see TSUKADA, at least 0196, Fig. 17, and associated text). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated TSUKADA’s teaching into Bedekar’s teaching for further alerting the user of issues within managed devices of the share space; accordingly, promoting effectiveness in maintenance within managed device of a shared space. As to claim 18, modified Bedekar with TSUKADA discloses further comprising instructions to cause the one or more processors to: gather the information regarding the plurality of conference rooms from a plurality of user devices— (e.g., the room health monitor 132 of the management cloud 104 may analyze and asses the obtained room health data from the peripheral device 114-128of the conference room 112 or other conference rooms – see Bedekar, at least 0017, 0027, 0035-0036, 0052, Figs. 1-3 and associated text). As to claim 19, modified Bedekar with TSUKADA discloses wherein the remediation package includes instructions to apply a firmware update to the first peripheral device --(e.g., the management cloud 104 may also transmit remediation tasks …remediations may include peripheral-specific tasks, such as updating drivers or firmware—see Bedekar, at least 0036-0037, 0039--0045, 0056, FIG. 1, Fig. 2, FIG. 5, and associated text). 11. Claim 11, 15, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bedekar in view of TSUKADA, and in further view of Hope et al. (US 20140074570 A1, hereinafter Hope). As per claims 11 and 20, it is to note that while modified Bedekar with TUSKADA discloses coordinate with the user to apply a remediation package to the first peripheral device – see Bedekar, at least 0036-0037, 0039-0045, 0053, 0056. 0061, Figs. 1-3, Fig. 5, and associated text, but the modified does not explicitly disclose; however, Hope, in an analogous art, discloses further comprising computer-readable instructions to cause the IHS to: ask the user for permission to move forward with a remediation operation; and proceed with coordinating with the user upon receiving permission from the user – (E.g., permission data 370 indicates each type of permission request made …and the corresponding response of the user. Permission data 370 indicates user 300 was asked to give permission for flashlight application 310 to engage in network communication, …, perform automatic updates, and check the status of any software installations. Permission data 370 also indicates user 300 gave permission for each of the permission requests—See Hope, at least 0087, Fig. 12b and associated text). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated Hope’s teaching into modified teaching of Bedekar with TSUKADA for further getting the user approving of installation within managed devices of the share space; accordingly, promoting effectiveness in maintenance within managed device of a shared space. As to claim 15, it is to note that while modified Bedekar with TUSKADA discloses coordinate with the user to apply a remediation package to the first peripheral device – see Bedekar, at least 0036-0037, 0039-0045, 0053, 0056. 0061, Figs. 1-3, Fig. 5, and associated text, but the modified does not explicitly disclose; however, Hope, in an analogous art, discloses further comprising computer-readable instructions to cause the IHS to: pre-authorize the user to apply the remediation package to the first peripheral device --(E.g., permission data 370 indicates each type of permission request made …and the corresponding response of the user. Permission data 370 indicates user 300 was asked to give permission for flashlight application 310 to engage in network communication…perform automatic updates, and check the status of any software installations. Permission data 370 also indicates user 300 gave permission for each of the permission requests—See Hope, at least 0087, Fig. 12b and associated text). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated Hope’s teaching into modified teaching of Bedekar with TSUKADA for further getting the user approving of installation within managed devices of the share space; accordingly, promoting effectiveness in maintenance within managed device of a shared space. 12. Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Bedekar in view of TSUKADA and in further view of Ichikawa et al. (US 20040260939 A1, hereinafter Ichikawa). As to claim 14, it is to note that while modified Bedekar with TUSKADA discloses the remediation package --(E.g., In the event that the room health assessment indicates an issue or failure of components within the conference room, the management cloud 104 may transmit remediation tasks …remediations may include peripheral-specific tasks, such as updating drivers or firmware…the management cloud 104 may also transmit remediation tasks or strategies to a user… the user can be a member of the organization that controls or owns the corresponding shared space – see Bedekar, at least 0036-0037, 0039-0045, 0053, 0056. 0061, Figs. 1-3, Fig. 5, and associated text), but the modified does not explicitly disclose; however, Ichikawa, in an analogous art, discloses wherein the remediation package includes instructions for the user to acquire an update patch or firmware update code using a web browser – (E.g., when a user requests upgrading Java-AP software, user need obtain an upgraded version of the JAR file using a package URL contained in the ADF of the Java-AP software. Namely, a mobile station first checks an ADF, then downloads a target JAR file of Java-AP software via web browser – see at least 0041, 0042, 0094, and 0149). Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated Ichikawa’s teaching into modified teaching of Bedekar with TSUKADA for further securing firmware installation within managed devices of the share space; accordingly, promoting effectiveness in maintenance within managed device of a shared space. 13. Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Bedekar in view of TSUKADA, Hope, and in further view of Nalukurthy et al. (US 20180343562 A1, hereinafter Nalukurthy). As to claim 16, it is to note that while modified Bedekar with TUSKADA and Hope discloses wherein the computer-readable instructions to cause the IHS to pre-authorize the user—See Hope, at least 0087, Fig. 12b and associated text, but the modified does not explicitly disclose; however, Nalukurthy, in an analogous art, discloses includes computer-readable instructions to cause the IHS to: send a one-time password to the user via out of band communication—(E.g., providing a secured password and authentication mechanism for programming and updating software and firmware via transmit the onetime password or security token to a user device—see Nalukurthy, at least 0013, and 0023) . Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated Hope’s teaching into modified teaching of Bedekar with TSUKADA for further securing firmware installation within managed devices of the share space; accordingly, promoting effectiveness in maintenance within managed device of a shared space. Conclusion 14. The prior art made of record and not relied upon (cited on 892 form) is considered pertinent to application disclosure. Fu et al. (US-20240048440-A1) discloses device management system for upgrading telephony device firmware. Thiruchengode Vajravel et al. (US-20250119462-A1) disclose diagnosing and remediating conference room peripheral devices via connected and authenticated user devices. 15. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MARINA LEE whose telephone number is (571)270-1648. The examiner can normally be reached Monday to Friday (8 am to 4: 30 pm ET). 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, Hyung S. Sough can be reached on (571)-272-6799. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. /MARINA LEE/Primary Examiner, Art Unit 2192
Read full office action

Prosecution Timeline

Oct 09, 2023
Application Filed
Jan 26, 2026
Non-Final Rejection — §103 (current)

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12596541
CLONING A CLOUD-AGNOSTIC DEPLOYMENT
2y 5m to grant Granted Apr 07, 2026
Patent 12591424
MANAGING APPLICATION UPDATES
2y 5m to grant Granted Mar 31, 2026
Patent 12585455
SERVER, NON-TRANSITORY STORAGE MEDIUM, AND SOFTWARE UPDATE METHOD
2y 5m to grant Granted Mar 24, 2026
Patent 12587513
CYPHERGENICS-ENABLED DIGITAL ECOSYSTEMS AND CYPHERGENICS-ENABLED DIGITAL SIGNATURES
2y 5m to grant Granted Mar 24, 2026
Patent 12572350
APPARATUS AND METHOD FOR OPTIMALLY UPDATING VEHICLE CONTROLLER
2y 5m to grant Granted Mar 10, 2026
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

1-2
Expected OA Rounds
85%
Grant Probability
99%
With Interview (+18.6%)
2y 9m
Median Time to Grant
Low
PTA Risk
Based on 646 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month