DETAILED ACTION
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 Action is responsive to the communication filed on 10/21/2025. The claim(s) 1- 20 is/are pending, of which the claim(s) 1 & 17 is/are in independent form.
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Response to Arguments
Applicant’s arguments with respect to amended limitations of the claim(s) 1 against the outstanding 103 rejections have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Specifically, newly cited reference Wang et al. (US 10884475 B1: See fig. 9, 1S908 & S916) is relied on to teach the challenged limitations.
Claim Objections
Claims 1- 16 & 20 objected to because of the following informalities:
Regarding claim 1, in lines 4 and 6, the phrases “at least one network;” and “wherein the one or more power devices are connected to the at least one network” should be written as “at least one communication network” and “wherein the one or more power devices are connected to the at least one communication network” respectively in order to clarify its relationship with “a power network” of line 2 so that power network and communication network are clearly distinguishable.
Regarding claims 2- 16 & 20, they are also objected to because of their direct or indirect dependency with objected claim 1.
Regarding claim 2, “at least one network” should be “at least one communication network” in line 3 and the last line.
Appropriate correction/clarification is required.
Claim Rejections - 35 USC § 103
Claim(s) 1, 4- 16, & 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Decamp et al. (US 20200219036 A1) in view of Takada et al. (US 20200408847 A1), and further in view of Wang et al. (US 10884475 B1).
Decamp and Takada are references of the record. The combination of Decamp, Takada, and Wang is referred as DTW hereinafter.
Regarding claim 1, Decamp teaches a system [“block diagram of a system 100 to manage a workspace 102,”] for providing information corresponding to one or more power devices [items (see fig. 2) connected to the “peripheral device ports 110” of the docking station 106, e.g., “displays 216 and accessories 212 of FIG. 2)”] that are components of a power network; the system comprising: (Figs. 1- 2 [022, 033, 056]);
- at least one network [“communicate with a network 114”] (fig. 1));
- a user device [the “system computer 138” of fig. 1 for “Information Technology(IT) personnel to perform remote diagnostics”] connected to the at least one network ([018, 0023], fig. 1);
- a hub [“docking station 106”] for routing messages and power between the one or more power device and the user device; wherein the one or more power devices are connected to the at least one network ([022-023, 034]);
- wherein the user device comprises a display device, a user device processor, and a user device memory having stored thereon a user device power application including a plurality of machine executable instructions that, when executed by the user device processor, cause the user device processor to: (the system computer 138 includes a display that shows a user GUI as shown in Figs. 3- 13);
[a] receive [“docking station 106 is configured to detect how much power is drawn from each of its peripheral device ports 110 and report the power consumption information to the system computer 138”], from the hub, one or more live power messages, each of the one or more live power messages comprising live power data comprising one or more of: a value of instantaneous power drawn from the hub by one or more power loads comprising the one or (claim requires only one limitation) more power devices ([0033-034]); and
- an amount of power available [“In some embodiments, the docking station 106 may also be configured to monitor how much power is drawn from other power sources (e.g., the desktop AC and USB power 204 and/or the smart power 202 of FIG. 2) within the corresponding workstation 104”] from one or more power sources [“smart power” 202] comprising the one or more power devices ([0033]);
- retrieve, from a historical power data store, historical power data [“to expected power consumption profiles to identify”] corresponding to each of the one or more power devices ([034, 049, 064]);
determine, based at least upon the value of instantaneous power drawn from the hub by the one or more power loads, the amount of power available from the one or more power sources, and the historical power data, a prediction [“ability to monitor and/or predict use of the workstations 104”, “determined that the device is malfunctioning or needs maintenance”] of usage duration/malfunctioning information
display, on the display device of the user device, a user interface (UI) layout comprising an indication of the warning and usage duration/malfunction information
Decamp teaches:
[0034] The reporting, by the docking station 106 at each of the workstations 104, to the system computer 138 of the power consumption information enables the system computer 138 to provide analytics regarding power consumption on a region level, an office level, a floor level, a zone level, a desk level, etc. (e.g., see FIGS. 3-6 and 9). These analytics may be detailed enough to show how much power is used by each port of the peripheral device ports 110 and ports of other power sources (e.g., see FIG. 9). These analytics may be displayed on UIs, printed, provided via emails to relevant personnel, or used and/or reported in other ways.
[0090] The alerts displayed in the alerts display field 1214 may be narrowed by user selections of options within a critical alerts field 1202, a warnings field 1204, and a notifications field 1206. The critical alerts field 1202 includes a connectivity loss option, an internal temperature option, and an escalated alerts field. A user selection of any of these options in the critical alerts field 1202 will cause the alerts display field 1214 to only display a corresponding subset of all the alerts of the selected area.
[0091] The warnings field 1204 includes a battery levels option, a power consumption option, a usage duration option, an unauthorized access option, and an ambient sensor threshold option. User selections of these options of the warnings field 1204 would cause the alerts display field 1214 to display only those of the alerts that concern battery levels (e.g., of the sensor 128, IoT sensor pack 210, etc.), power consumption, usage duration, unauthorized access, and ambient sensor threshold, respectively. The notifications field 1206 includes a new updates available option and an override events option. User selections of these options of the notifications field 1206 would cause the alerts display field 1214 to display only those of the alerts that concern new updates that are available and override events, respectively.
PNG
media_image1.png
526
706
media_image1.png
Greyscale
In summary, Decamp teaches a user device processor for generating and displaying of various warnings/alerts based on power consumption of individual or total power consumption information for one or more power loads (items 212, 216 of fig. 2) of multiple zones of the office and displaying the predicted information in a user interface (paras. 020-022).
However, Decamp fails to teach or suggest such generated and displayed predicted/calculated information to include “a prediction of a remaining run time of the one or more power loads” as claimed. That is, Decamp fails to teach the processor to
(1) determine and display a prediction of a remaining run time of the one or more power loads and displaying of the remaining run time,
(2) the determined remaining run time is refined based on the historical power data to improve estimation accuracy over time;
(3) based on the determined remaining run time, adjust one or more operational parameters of the hub or of at least one of the power devices to manage available power, including selectively reducing power to one or more non-critical loads or prioritizing charging of the one or more power sources.
Takada relates to estimating loads connected to a power system and determining whether the available power is sufficient to finish execution of the load(s) 17 and generate a warning ([046], Fig. 3). Specifically, Takada teaches a power system [“load estimation device 100”, analogous to Decamp’s system 100] with a hub device [“power source circuit 3 to supply power to the load from both the engine-driven generator 2 and the storage battery 14”, analogous to Decamp’s docking station 106] comprising a power supply source [battery 14] and pluralities of the power loads comprising power devices [“plurality of loads 17 to be connected”, analogous to peripherals connected to the docking station of Decamp] comprising a user device with a processor [CPU of the control circuit 11] coupled with a display device 13 (Figs. 1-3, [025-026, 056]). More specifically, Takada teaches a user device processor [“CPU 21” of the control circuit 11] to:
determine [“calculates a remaining operating time (h)”], based at least upon the value of instantaneous power drawn from the hub by the one or more power loads, the amount of power available from the one or more power sources, and the historical power data [e.g., “that a typical amount of power required by a rice cooker from the start to the end of rice cooking is known”], a prediction of a remaining run time [“operating time calculating unit 25 calculates a remaining operating time (h) basically from an instantaneous value (W) of the power consumed by all the loads at present and a suppliable power amount (Wh) found from the remaining amount of fuel, the charge, and so on”] of the one or more power loads (Fig. 7, [024, 027, 036, 045]); and
display [“outputs the remaining operating time to the display device 13”], on the display device of the user device, a user interface (UI) layout comprising an indication of the determined remaining run time of the one or more loads (Fig. 7, [031, 036, 045-046, 055]);
based on the determined remaining run time [“the sum of the power consumption of the estimated load and the power consumption of the predicted load is greater than the power generating capability…moves the sequence to S14… to start charging the storage battery 14”. The load being greater than power capability relates to remaining run time here], adjust one or more operational parameters of the hub or of at least one of the power devices to manage available power, including selectively reducing power to one or more non-critical loads or prioritizing charging [“the CPU 21 (the power supply control unit 31) controls the charging circuit 8 to start charging the storage battery 14”] of the one or more power sources [storage battery 14 of fig. 3] ([055-056]).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to (1) combine Takada and Decamp because they both related to a power hub coupled with pluralities of the power load devices via ports and (2) modify the user device processor of Decamp to determine, display a remaining run time of the one or more power devices and for one or more power devices and adjust operational parameters of the power devices as in Takada. Doing so would avoid the situation of having insufficient power to finish executing of one or more tasks of the power devices (peripheral devices) connected into the ports of the docking station 106 of the Decamp and notifying the users about the remaining time so that they can take appropriate control action(s) (Hauser [056, 058], Decamp fig. 2).
Accordingly, Decamp in view of Takada teaches all limitations of the claim except: (2) the determined remaining run time is refined based on the historical power data to improve estimation accuracy over time. Put differently, Decamp in view of Takada fails to teach its determined run time is refined type of the run time by considering historical power data to improve the estimation accuracy over time.
Wang relates to power management while executing various operational loads in an electronic device 100/200 with a power source (battery 214) to determine and extend the device run time (Figs. 1-2, 7). Specifically, Wang teaches a system for providing managing information corresponding to one or more power devices, the system comprising: a user device processor to:
determine [step 910 of fig. 9: “determining the remaining device run-time for the device”], based at least upon the value of instantaneous power drawn by one or more power loads, the amount of power available from the one or more power sources, and the historical power data, a remaining run time of the one or more power loads, wherein the determined remaining run time is refined [“perform averaging operations on the present and previous values for P.sub.t that are stored in memory 204 across the predetermined time period to produce a value for the average power usage P.sub.ave for device 200”, “determining an average power usage for the device by averaging prior power usage values”] based on the historical power data to improve [using of the averaging increases the estimation accuracy by reducing impact of noisy or outlier readings] estimation accuracy over time (Col 18, lines 40- 60, Claim 12);
based on [Yes on step 914 for the determined remaining run time of the step 912] the determined remaining run time, adjust [steps 914 and 916 of fig. 9: perform power management functions] one or more operational parameters of the hub or of at least one of the power devices to manage available power, including selectively reducing [“throttling the performance of or disabling operations being performed by or applications running on device 200… in order to reduce power usage and thereby increase remaining device run-time t.sub.rem. The order in which device operations (e.g., functions or a… task-based priority difference will be reflected”] power to one or more non-critical loads [“WiFi and GPS functions may be disabled,”, the claim covers software and hardware loads] or prioritizing charging of the one or more power sources (Col 19 lines 20- 60).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to (1) combine Wang and Decamp in view of Takada because they both related to determining remaining runtime for one or more power devices and (2) modify the system of Decamp in view of Takada to have its determined remaining time refined and updated based on the historical power data as in Hauser. Doing so would avoid the situation where the determined remaining time is improperly impacted by some noisy or outlier readings and increase the accuracy of the determining of the remaining run time (Col 18 lines 50- 55). Accordingly, Decamp, Takada, and Wang combines to teach each limitations of the claim and renders invention of this claim obvious to PHOSITA.
Regarding claim 4, DTW further teaches the system of claim 1, wherein the user device power application further comprises machine executable instructions that, when executed by the user device processor, further cause the user device processor to generate, based on the live power data, at least one statistical power product [“main dashboard UI 300 includes a total power consumed today field 318”]; and wherein the UI layout further comprises the at least one statistical power information product (Decamp [055, 063-064]).
Regarding claim 5, DTW further teaches the system of claim 4, wherein the at least one statistical power information product comprises a value of a sum of the instantaneous power drawn from the hub by each of the of the one or more power loads (Decamp [055, 063-064]).
Regarding claim 6, DTW further teaches the system of claim 4, wherein the at least one statistical power information product includes a value [“suppliable power amount (Wh) found from the…the charge”] of an amount of total power available from the one or more power sources (Takada [036-037], Wang Col 16 lines 1-10).
Regarding claim 7, DTW further teaches/suggests the system of claim 1, wherein the user device power application further includes machine executable instructions that, when executed by the user device processor, further cause the user device processor to: compare a value of the prediction of the remaining run time of the one or more power loads to a threshold value and, based on the comparison, generate an alert [“warning indicating that the estimated load will be unable to complete its main objective” in Takada, “notify the user via a popup notification or another desired type of alert” in Wang]; and include the alert on the UI layout (Takada [045-046], Wang Col 21 lines 20-30).
Regarding claim 8, DTW further teaches the system of claim 7, wherein the user device power application further includes machine executable instructions that, when executed by the user device processor, further cause the user device processor to communicate the alert to an endpoint device [“may transmit the continuous operation time to an external information processing device”] that is connected to a second network, the second network being different from the power network (Takada [031]; Wang Col 21 lines 20-30).
Regarding claim 9, DTW further teaches/suggests the system of claim 1, wherein the user device power application further includes machine executable instructions that, when executed by the user device processor, further cause the user device processor to: determine an identity [“the system computer may be configured to automatically discover all electronic assets in the system”] of each of the one or more power devices; and retrieve, from the historical power database, historical power data corresponding to the identity of each of the one or more power devices (Decamp [0049]; Takada [019, 050]).
Regarding claim 10, DTW further teaches/suggests the system of claim 1, wherein the user device memory includes a user device live power data store stored thereon, and wherein the user device power application further includes machine executable instructions that, when executed by the user device processor, further cause the user device processor to store [“the system computer 138 to provide analytics regarding power consumption on a region level, an office level,” means storing the data at the computer 138 before the data can be used for analytics] the live power data in the user device live power data store (Decamp [034]).
Regarding claim 11, DTW further teaches/suggests the system of claim 10, wherein the hub memory includes a hub power data store having stored therein at least a portion of the live power data (Decamp [034, 049] & Takada [037]).
Regarding claim 12, DTW further teaches/suggests the system of claim 11, wherein the user device power application further includes machine executable instructions that, when executed by the user device processor, further cause the user device processor to request [“provide a search bar to enable the user to search”] live power data from the hub power data store (Decamp [069]).
Regarding claim 13, DTW further teaches/suggests the system of claim 11, wherein the live power data stored in the user device live power data power store includes associated mission metadata [“particular user”, or “user to search (e.g., text search) the text field for any detected asset”], and wherein the selected portion of the live power data is selected for inclusion in the historical power database based on a comparison of the associated mission metadata with one or more characteristics of a planned mission (Decamp [019, 086]).
Regarding claim 14, DTW further teaches/suggests the system of claim 10, wherein the historical power data store includes a selected portion of the live power data stored in the user device live data power store (Decamp [0049]) & Takada [037]).
Regarding claim 15, DTW further teaches/suggests the system of claim 4, wherein the user device power application further includes machine executable instructions that, when executed by the user device processor, further cause the user device processor to communicate the statistical power information product to an endpoint device that is connected to a second network [“analytics may be displayed on UIs, printed, provided via emails to relevant personnel”], the second network being separate from the power network (Decamp [0034]).
Regarding claim 16, DTW further teaches/suggests the system of claim 1, wherein the user device comprises an end user device (EUD) [e.g., a computer device 132 of Decamp or device 11 of Takada] or a smart watch and wherein the one or more power loads comprises the user device (Decamp Figs. 1- 2 [022, 042] Takada fig. 2).
Regarding claim 20, DTW teaches the power monitoring hub of claim 1, wherein the hub processor automatically detects connection or disconnection of a power device at a hub port and updates monitoring operations accordingly (Decamp, [050], Fig. 2).
Claim(s) 2- 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over DTW as applied to claim 1 above, and further in view of Chen et al. (US 20080215694 A1, reference of the record).
Regarding claim 2, Decamp in view of Takada further teaches the system of claim 1 wherein the hub [docking station 106] includes a power consumption data reported to the system computer 138 may be used to identify devices that are drawing power”] the
While DTW teaches of exchanging message from pluralities of the different types of power devices (items 212 210) to a hub (docking station) [item 106] and from the hub to a user device [‘system computer 138’] (Decamp, figs. 1-2), it still fails to teach the hub to include a uniform messaging service and a uniform bridge format message as claimed and shown with strikethrough emphasis. But this deficiency is cured by Chen.
Chen teaches a hub for routing messages and power includes a uniform messaging service [unified messaging system 100] comprising: a device interface that is communicatively coupled to the hub and the at least one network; a hub processor ([027]); a hub memory having stored thereon a hub uniform messaging application including a plurality of machine executable instructions that, when executed by the hub processor, cause the hub processor to: ([028-032]);
receive two or more live power messages from two or more of the one or more power devices [user 1’s devices, analogous to peripheral devices connected to adapter 106], the live power messages comprising the live power data; generate, based upon the two or more live power messages, a uniform bridge format [“At step 204, the message generated by the sender and received by the system 100 through the bearer connection component 101 is converted into a unified format message”] message comprising the live power data; and output [delivering the message to recipient like user 2, analogous to Decamp’s computer system 138] the uniform bridge format message to the at least one network for transmission to the user device ([028-032, 046]).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to (1) combine Chen and DTW because they both related to pluralities of the power devices sending messages to a user device using a hub device and (2) modify the system of DTW to include missing limitations. Doing so would allow the DTW’s the docking station to receive messages from its diverse peripherals (e.g., items 212 of Decamp) and successfully send the message to the user device (system computer 138) in a most suitable format without modifying existing communication protocols (Chen [012]).
Regarding claim 3, DTW and Chen further teaches the system of claim 2, wherein the user device includes a user device uniform messaging application stored in the user device memory, the user device uniform messaging application including one or more machine executable instructions that when executed by the user device processor, cause the user device processor to: receive the uniform bridge format message; generate, based on the uniform bridge format message, the two or more live power messages; and provide the two or more live power messages to the power application (Decamp, figs. 1- 2 & Chen [028- 032, 046]).
Claim(s) 17 is/are rejected under 35 U.S.C. 103 as being unpatentable over Decamp in view of Hauser (US 20080289004 A1).
Regarding claim 17, Decamp teaches a power monitoring hub [one of the docking stations 106 of the system 100] comprising: (Figs. 1- 2);
a housing including a plurality of hub ports [“docking station 106 is also connected to one or more accessories 212 (e.g., via the peripheral device ports 110 of FIG. 1),”], each hub port configured to connect to a power device [“Each docking station 106 includes a power input 108 and a network interface 112 to communicate with a network 114”, e.g., smart power 202] ([022, 056]);
a hub processor [CPU (inherent or well-known to be included) of the station 106] disposed within the housing and coupled to the plurality of hub ports (Figs. 1-+ 2);
a plurality of power monitoring circuits [circuits that track power consumption of each of the peripherals like items 216, 210 as part of “power consumption data reported to the system computer 138 may be used to identify devices that are drawing power”] each associated with a respective one of the hub ports, each power monitoring circuit configured to measure voltage and current corresponding to the connected power device; and a hub memory [memory (e.g., item 130) used by the station 106] coupled to the hub processor; wherein the hub processor is configured to:(a) obtain, from the plurality of power monitoring circuits, real-time voltage and current data corresponding to each hub port (Fig. 2, [033-034, 037]);
compute peak and average power values based on the voltage and current data over a configurable time interval;(c) store the voltage, current, and power data in the hub memory as power log data ([032-033, 064, 068], fig. 3); and
(d) generate a data message [information sent/transmitted from the docking station 106 to the other devices like cloud 214/system computer 138] including the power log data .g., system computer 138/user device 140] (Fig. 1-2, [049-050]).
Decamp fails to teach its transmitted data are formatted in a standardized message structure for transmission to an external user device.
However, transmitting data from a first network device (like docking station 106 of Decamp) to the another network device (system computer 138) is well-known to have utilized “standardized message structure” as claimed.
For example, Hauser teaches a computing device [node] comprising a processor to generate a data message including the log data formatted in a standardized message structure [“based on standarized protocols like TCP/IP or InfiniBand”] for transmission to an external user device ([002, 036, 088]).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to (1) combine Hauser and Decamp because they both related to transmitting information from one computing device to another computing device using a network and (2) modify the hub processor of the docking station 106 of Decamp to have its generated data message including the power log data to be transmitted to other computing devices (like device 138) formatted in a standardized message structure for transmission as in Hauser. Doing so would help minimize the service attacks while performing data exchange between the docking station 106 and the computing device 138 in the system of Decamp (Hauser [003- 004]).
Claim(s) 18 -19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Decamp in view of Hauser (US 20080289004 A1), and further in view of Lin et al. (US 20160202748 A1). The combination of Decamp, Hauser, and Lin is referred as DHL hereinafter.
Regarding claim 18, Decamp in view of Hauser teaches the power monitoring hub of claim 17, wherein the hub processor [processor of the docking station 106] is further configured to: communicate, via an smart power 202] connected to one of the hub ports to obtain battery data including at least one of a state of charge, a state of health, or a temperature of the battery, and to combine the battery data with the power log data (Decamp, Fig. 2, [036, 074, 084]).
Decamp in view of Hauser silent about stating the communication protocol it uses to allow the communication between the battery and the docking station.
Lin teaches a power monitoring hub [“docking station 12”] comprising a processor configured to: communicate, via an SMBus protocol [“battery power information of the docking battery 120 by the I.sup.2C or SMBus communication protocol (S410)”], with a battery [“the docking battery 120”] connected to one of the hub ports to obtain battery data including at least one of a state of charge, a state of health, or a temperature of the battery, and to combine the battery data with the power log data ([020, 027]).
It would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to (1) combine Lin and Decamp in view of Hauser because they both related to docking station connected with a power source and (2) modify the docking station of Decamp in view of Hauser to utilize SMBus protocol to communicate with its power source to obtain the battery data as in Lin. Lin teaches an exemplary communication protocol that Decamp in view of Hauser’s docking station can utilize to successfully communicate/transmit data with its battery. Thus, DHL teach each limitation of the claim and renders invention of this claim obvious to PHOSITA.
Regarding claim 19, DHL teaches the power monitoring hub of claim 18, wherein the hub processor automatically detects an SMBus-compatible battery connected to a hub port and retrieves the battery data at each configurable time interval (Decamp, Fig. 2, [036, 074, 084] & Lin [022]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Contacts
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SANTOSH R. POUDEL whose telephone number is (571)272-2347. The examiner can normally be reached Monday - Friday (8:30 am - 5:00 pm).
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, Thomas Lee can be reached on 571-272-3667. 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.
/SANTOSH R POUDEL/Primary Examiner, Art Unit 2115
1 Col. 18 Lines 42- 55: “ At step 908, multiple values for P.sub.t across a predetermined time period are accessed from memory and are averaged to determine average power usage P.sub.ave for the predetermined time period. For example, processor 202 may perform averaging operations on the present and previous values for P.sub.t that are stored in memory 204 across the predetermined time period to produce a value for the average power usage P.sub.ave for device 200 across the predetermined time period. By averaging recent P.sub.t values in this way, the impact of noisy or outlier P.sub.t readings may be reduced when calculating the remaining device run-time at step 910. As shown, steps 902 and 904 may be performed in parallel with steps 906 and 908, if desired