DETAILED ACTION
1. This action is responsive to the communications filed on 07/03/2025.
2. Claims 1, 3-8, are pending in this application.
3. Claims 1, 6, 7, have been amended.
4. Claim 2 has been previously cancelled.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 08/07/2025 has been entered.
Response to Arguments
Applicant's arguments filed 07/03/2025 have been fully considered but they are not persuasive. In the remarks, applicant argued that:
a. Williams discloses a mechanism for controlling software updates across distributed clients using a download acceptance percentage and download regulation files (ORFs). In paragraph [40], Williams teaches that this percentage may be compared with a randomly generated number at the client to probabilistically determine whether the client is permitted to download the update.
However, Williams does not disclose or suggest that the acceptance percentage or predetermined probability is based on the size of the new data. Instead, Williams
appears to use the acceptance percentage uniformly across client devices for purposes such as throttling downloads or controlling server load (see, e.g., paras. [40], [52]).
Paragraph [52] of Williams describes gradually raising the acceptance percentage over time, but this variation is temporal and possibly user-specific-not data-specific. Nowhere does Williams teach or suggest dynamically adjusting the probability based on the size of the software update or content to be downloaded (Applicant’s remarks, pages 5-6).
In response: The examiner respectfully disagrees.
Williams discloses that based on gathered network server and data center statistics, along with criteria such as the size of the update, a set of information is created, provided to the client, and regularly updated. The set of information controls the clients downloading behavior and is provided to the clients in the form of a Download Regulation File (DRF) that contains parameters in the form of a download acceptance percentage and a download time value. The download acceptance percentage is a probability related value that instructs each client as to whether that client should start a download (Paragraphs 11-12 and 46). Williams goes on to disclose that those statistics (e.g., network statistics, load of servers, size of the update, currently known network problems) are collected, and based on those statistics, the DRF is created and thereafter regularly updated.
Therefore, the rejection is respectfully maintained.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3-8 are rejected under 35 U.S.C. 103 as being unpatentable over Williams et al. (US 2005/0120040) in view of Matthew et al. (US 2014/0282480).
Regarding claim 1, Williams disclosed:
An electronic device (Figure 1, computer 110) comprising:
a communication device (Figure 1, network interface 170) configured to communicate with a server device (Figure 1, remote computer 180) that provides data (Paragraph 33, software updates) (Paragraph 31, remote computer being a server);
a storage device (Figure 1, hard disk drive 141); and
a control device (Figure 1, processing unit 120) that
determines if a current time (Paragraph 45, expiration of wait time) has passed an update check date and time (Paragraph 45, wait time) (Paragraph 43, clients must meet an acceptance percentage in order to request an update. Paragraph 45, the download time represents a wait time before attempting to download an update. Paragraph 46, upon expiration of the wait time for a system that is not currently downloading, the download regulation file (DRF) is re-read and the determination is performed again as to whether to start downloading or to wait further);
accesses the server device if the current time has passed the update check date and time, using the communication device to check whether or not new (Paragraph 36, update) data has been provided from the server device (Paragraph 36, client computer executes daily, a program to connect to one or more update servers to see whether any new software updates are available. Paragraph 47, Figure 3, client computer 208 sends a request for content and downloads a copy of a current download regulation file (DRF). If the client system is directed to wait based on the information in the download regulation file, it will wait for a time specified in the download time window and repeat steps 300 (sending a request) and 302 (receiving a DRF) (i.e., accessing). Paragraph 48, if the system determines that it should start a download, the client will go ahead with the update),
determines, based on a predetermined probability (Paragraph 42, download acceptance percentage), whether to download the new data from the server device or to postpone download when the new data has been provided (Paragraph 42, each DRF contains a download acceptance percentage and a download time. The download acceptance percentage comprises a value that informs the clients on what the probability is that they should start the download based on a randomly generated number. For example, all clients that generated below 0.7 will download the data. Clients that generated random numbers that do not meet the threshold value corresponding to the acceptance percentage back off and try again later (i.e., postpone)), and
stores, in the storage device, the new data downloaded from the server device (Paragraph 45, downloading the file to the client);
wherein the predetermined probability is set based on the size of the new data (Paragraph 39, the information in the DRF, which includes the download acceptance percentage (see Paragraph 42), is based on network statistics and loads of the update servers as well as based on the loads for server data centers that propagate the updates. Other criteria is factored in, such as the size of the update along with general network information such as currently known network problems. To this end, a network/server statistics collector 220 is used to collect the statistics (including any other criteria, such as the aforementioned size of the update) and based on these statistics, the DRF is created and thereafter regularly updated by a DRF parameter calculation mechanism. Paragraph 46, In the latest download regulation file, the acceptance percentage and time window parameters may have changed by the regular evaluation of load statistics. Paragraph 11-12, the size of the update is part of the set of information that is created and provided to the client. The set of information controls the client’s downloading behavior);
While Williams disclosed accessing the server device periodically (Paragraph 47), Williams did not explicitly disclose an update check date and time which is set to cycle every 7 days or more when the electronic device is started up.
However, in an analogous art, Matthew disclosed an update check date and time, which is set to cycle every 7 days or more, when the electronic device is started up (Paragraph 51, checking for the availability of different type of updates with different frequencies. The time interval for checking for updates is reset once the update is checked (i.e., cycle). Checking for critical updates once a week (i.e., 7 days or more). If the device is turned off, the actual date and time of the last check for updates is compared to a current date and time to determine whether to check for updates again, process proceeds to step 350 (Figure 3B), Paragraph 137, when the device is turned on).
One of ordinary skill in the art would have been motivated to combine the teachings of Williams with Matthew because the references involve checking for updates, and as such, are within the same environment.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate the update check every 7 days or more of Matthew with the teachings of Williams in order reduce the amount of download and evaluation of the updates at the client device (Matthew, Paragraph 74).
Regarding claims 6, 7, the claims are substantially similar to claim 1.
Claim 6 recites a server device (Williams, Figure 2, content update servers 212) that is connected to, communicates with, and provides data to the electronic device (Williams, Paragraphs 36-37). Therefore, the claims are rejected under the same rationale.
Regarding claim 3, the limitations of claim 1 have been addressed. Williams and Matthew disclosed:
wherein when the new data has been provided and the control device determines to postpone download of the new data based on the probability (Williams, Paragraph 42, clients that generated random numbers that do not meet the threshold value corresponding to the acceptance percentage back off and try again later),
the control device increases the probability (Williams, Paragraph 54, the parameters may be set to initially start the DRF with a lower acceptance percentage and then gradually raise the acceptance percentage), and
after a lapse of a predetermined time length, redetermines, based on the increased probability, whether to download the new data from the server device or to postpone download (Williams, Paragraph 47, if the client system is directed to wait by the internal comparison, it will wait for a specified time in the download time window to re-read another DRF and re-decide if it should initiate the download).
Regarding claim 4, the limitations of claim 1 have been addressed. Williams and Matthew disclosed:
wherein when the new data has been provided and the control device determines to postpone download of the new data based on the probability (Williams, Paragraph 42, each DRF contains a download acceptance percentage and a download time. The download acceptance percentage comprises a value that informs the clients on what the probability is that they should start the download based on a randomly generated number. Clients that generated random numbers that do not meet the threshold value corresponding to the acceptance percentage back off and try again later),
the control device redetermines, after a lapse of a first random time length, based on the probability, whether to download the new data from the server device or to postpone download (Williams, Paragraph 47, if the client system is directed to wait by the internal comparison, it will wait for a specified time in the download time window to re-read another DRF and re-decide if it should initiate the download).
Regarding claim 5, the limitations of claim 1 have been addressed. Williams and Matthew disclosed:
wherein after a lapse of a second random time length after starting up the electronic device, the control device cyclically accesses the server device using the communication device to check whether or not the new data has been provided (Williams, Paragraph 47, after the time window has elapsed, client then re-reads another DRF and re-decides if it should initiate. If it does not initiate due to the probability, the process would start over where it would wait a certain time before re-reading yet another DRF).
Regarding claim 8, the limitations of claim 1 have been addressed. Williams and Matthew disclosed:
wherein when the current time has not passed the update check date and time, the control device waits a period shorter than the cycle, and then determines again if the current time has not passed the update check date and time (Matthew, Paragraph 51, determining whether it is time to check for security updates and if not, waits a predetermined amount of time before returning to step 305 (Figure 3A) of checking for updates. The time interval is determined by the elapsed time since the update was last checked. Some updates are checked for more often than other updates (i.e., shorter cycle)).
For motivation, please refer to claim 1.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Steven C. Nguyen whose telephone number is (571)270-5663. The examiner can normally be reached M-F 7AM - 3PM and alternatively, through e-mail at Steven.Nguyen2@USPTO.gov.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Christopher Parry can be reached at 571-272-8328. 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.
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.
/S.C.N/Examiner, Art Unit 2451
/Chris Parry/Supervisory Patent Examiner, Art Unit 2451