DETAILED ACTION
This office action is in response to the amendment filed February 27, 2026.
Claims 1-11 are pending.
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 .
Response to Arguments
Applicant’s arguments, see Remarks, February 27, 2026 with respect to the rejection(s) of claim(s) 1-11 under §103 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of prior art below.
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.
Claim(s) 1, 2, 5-8, and 11 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Ravoor” (US PG Pub 2022/0391190) in view of “Venkatesan” (US PG Pub 2013/0036413) ,“Huang” (US PG Pub 2015/0331780) and “Winnick” (US PG Pub 2015/0032669).
Regarding Claim 1, Ravoor teaches:
1. An apparatus comprising: a network interface; (See e.g. networked system fig. 1, and networks as discussed in ¶22) logic circuitry configured to: determine a past problem actually experienced by a device; (e.g. ¶95 configuration information including information indicating issues encountered by host devices is reported from host devices over the interface to networked support system)
Ravoor does not explicitly teach, but Venkatesan teaches:
determine problems fixed for the device by installing a software update and whether the problems comprise the past problem; (Venkatesan 202-204, Fig. 2, ¶¶22-23 teaches logging of support request from user for bug actually encounter by the user in the application, e.g from client device 540, Fig. 5; and further teaches ¶¶23-25, Software Release 330, Fixing bugs 321, 322, where e.g. 321 is associated with the previous request 310A Fig. 3, logged from client in 202, Fig 2, e.g. from client device 540, Fig 5)
and utilize the network interface to transmit a personalized message to the device, wherein the personalized message indicates … the software update will fix the past problem actually experienced by the device. (212 Fig. 2 , ¶¶26-27, customer associated with previous bug is notified of the software release that will fix the bug previously actually experienced by customer).
In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date combine the teachings of Ravoor and Venkatesan as each is directed to applying issue-fixing upgrades and Ravoor recognized the need to encourage proactive application of important update patches (e.g. ¶106) and Venkatsean recognized the previous flaw that “the customer reporting the bug in a support request is never directly notified that the bug has been fixed or otherwise addressed.” (¶4).
Ravoor further does not teach, but Huang teaches: how one of the issues to be fixed (Huang ¶29 teaches a entry in a defect report support database which indicates how customer support members fixed a defect)
In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date combine the teachings of Ravoor et. al. and with those of Huang is each is directed to applying fix updates and Huang recognized that indicating how a defect fixes a defect provides important information wherein “Without the information provided by the defect analysis system 120, the customer service team 116 member might have spent significantly more time troubleshooting the defect.” (¶29).
Ravoor further does not teach, but Winnick teaches:
determine the past problem actually experienced by the device comprises a problem determined based on a search of a past user interaction with a troubleshooting application on the device, wherein the troubleshooting application comprises steps for searching for a source of the problem; (Winnick fig. 3, ¶¶44-50 teaches user interaction with troubleshooting system which indicates a past problem actually experienced, where 306, the user indicates a problem encounters and 308-320 the troubleshooting system guides the user through troubleshooting steps to resolve the problem)
In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Ravoor with the teachings of Winnick as each is directed to software troubleshooting systems and Winnick recognized for program users “an urgent need exists for systems and methods for automating the troubleshooting process.” (¶11).
Claim 7 is rejected on the same basis as claim 1 above.
Regarding Claim 6, Ravoor teaches:
6. An apparatus comprising: at least one database configured to store a past problem actually experienced by a device (e.g. ¶95 configuration information including information indicating issues encountered by host devices is reported from host devices over the interface to networked support system; see further Ravoor issue database 220, 250, fig. 2)
a network interface; (See e.g. networked system fig. 1, and networks as discussed in ¶22)
and logic circuitry configured to: access the database to determine the past problem actually experienced by a device; (Ravoor e.g. ¶¶86, 92-93, 101, Fig. 2 and 3 describe a system which compares device configuration to host device configurations of updates which may fix issues encountered by a devise and determine whether it is advisable to apply the upgrade)
Ravoor does not explicitly teach, but Venkatesan teaches determine that the past problem actually experienced by the device is the same problem as the first problem fixed with the software update; (Venkatesan 202-204, Fig. 2, ¶¶22-23 teaches logging of support request from user for bug actually encounter by the user in the application, e.g from client device 540, Fig. 5; and further teaches ¶¶23-25, Software Release 330, Fixing bugs 321, 322, where e.g. 321 is associated with the previous request 310A Fig. 3, logged from client in 202, Fig 2, e.g. from client device 540, Fig 5)
and utilize the network interface to transmit a personalized message to the device, wherein the personalized message indicates… software update will fix the first problem actually experienced by the device, without mentioning the second or third problem. (212 Fig. 2 , ¶¶26-27, customer associated with previous bug is notified of the software release that will fix the bug previously actually experienced by customer; and embodiments in ¶27 do not include bugs non-linked to the support request in the email).
along with a first, a second, and a third problem fixed with a software update; and further teaches ¶¶23-25, Software Release 330, Fixing bugs 321, 322, where e.g. 321 is associated with the previous request 310A Fig. 3, logged from client in 202, Fig 2, e.g. from client device 540, Fig 5)
access the database to determine the first, second, and third problem fixed with the software update; and further teaches ¶¶23-25, Software Release 330, Fixing bugs 321, 322, where e.g. 321 is associated with the previous request 310A Fig. 3, logged from client in 202, Fig 2, e.g. from client device 540, Fig 5)
In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date combine the teachings of Ravoor and Venkatesan as each is directed to applying issue-fixing upgrades and Ravoor recognized the need to encourage proactive application of important update patches (e.g. ¶106) and Venkatsean recognized the previous flaw that “the customer reporting the bug in a support request is never directly notified that the bug has been fixed or otherwise addressed.” (¶4).
Ravoor further does not teach, but Huang teaches: how the software update will fix the first problem (Huang ¶29 teaches a entry in a defect report support database which indicates how customer support members fixed a defect)
In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date combine the teachings of Ravoor et. al. and with those of Huang is each is directed to applying fix updates and Huang recognized that indicating how a defect fixes a defect provides important information wherein “Without the information provided by the defect analysis system 120, the customer service team 116 member might have spent significantly more time troubleshooting the defect.” (¶29).
Ravoor further does not teach, but Winnick teaches:
determine the past problem actually experienced by the device comprises a problem determined based on a search of a past user interaction with a troubleshooting application on the device, wherein the troubleshooting application comprises steps for searching for a source of the problem; (Winnick fig. 3, ¶¶44-50 teaches user interaction with troubleshooting system which indicates a past problem actually experienced, where 306, the user indicates a problem encounters and 308-320 the troubleshooting system guides the user through troubleshooting steps to resolve the problem)
In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Ravoor with the teachings of Winnick as each is directed to software troubleshooting systems and Winnick recognized for program users “an urgent need exists for systems and methods for automating the troubleshooting process.” (¶11).
Regarding Claim 2, Ravoor et al teaches the limitations of claim 1 above but does not further teach, while Huang teaches:2. The apparatus of claim 1 wherein the past problems actually experienced by the device comprises a problem that was reported to a helpdesk. (Huang, ¶¶24,59 describes the user reporting device issues to a customer support system)
In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date combine the teachings of Ravoor et. al. and with those of Huang is each is directed to applying fix updates and Huang recognized the need that “As software increases in complexity, the difficulty in fixing defects can increase at a rate that might be characterized as exponential, or worse.” (¶3).
Claim 8 is rejected on the same basis as claim 2 above.
Claim(s) 3,5,9 and 11are rejected under 35 U.S.C. 103 as being unpatentable over “Ravoor” (US PG Pub 2022/0391190) in view of “Venkatesan” (US PG Pub 2013/0036413) ,“Huang” (US PG Pub 2015/0331780) and “Winnick” (US PG Pub 2015/0032669) as applied above and further in view of “Thangamani” (US PG Pub 2016/0292065)
Regarding Claim 3, Ravoor et al teach the limitations of claim 1 above, but do not further teach, while Thangamani teaches:
3. The apparatus of claim 1 wherein the past problems actually experienced by the device comprises a problem that was self reported by the device. (Thangamani e.g. ¶31 describes the telemetry collector used for collection device data related to issues for diagnosis and eventual fixing) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date combine the teachings of Ravoor et. Al. and with those of Thangamani as each is directed to applying fix updates and Thangamani recognized the need for “Techniques related to finding anomalies in telemetry data and finding correlations between anomalies and software updates…” (¶4).
Claims 9 is rejected on the same basis as claim 3 above.
Regarding Claim 5, Ravoor et al teach the limitations of claim 1 above, but do not further teach, while Thqangamani teaches:
5. The apparatus of claim 1 wherein the past problems actually experienced by the device comprises a problem that was reported by the troubleshooting application residing on the device. (Thangamani e.g. ¶31 describes the telemetry collector used for collection device data related to issues for diagnosis and eventual fixing) In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date combine the teachings of Ravoor et. Al. and with those of Thangamani as each is directed to applying fix updates and Thangamani recognized the need for “Techniques related to finding anomalies in telemetry data and finding correlations between anomalies and software updates…” (¶4).
Claim 11 is rejected on the same basis as claim 5 above.
Claim(s) 4 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Ravoor” (US PG Pub 2022/0391190) in view of “Venkatesan” (US PG Pub 2013/0036413) ,“Huang” (US PG Pub 2015/0331780) and “Winnick” (US PG Pub 2015/0032669) as applied above and further in view of “Tullis” (US PG Pub 202/0124028).
Regarding Claim 4, Ravoor et al teaches the limitations of claim 1 above but does not further teach, while Huang teaches:4. The apparatus of claim 1 wherein the past problems actually experienced by the device comprises a problem was determined via analyzing past internet searches for a user. (See e.g. Tullis ¶30, Fig. 10 teaches a system that analyzes the users history of internet searches to determine an intent of software to find)
In addition, it would have been obvious to one of ordinary skill in the art, prior to the effective filing date of the application to combine the teachings of Ravoor et al and Tullis as each is directed to provides desired software code for installation and Tullis recognized “user may be provided with search results including application information, data, metadata and direct links to an application store for download of a desired application.” (¶5)
Claim 10 is rejected on the same basis as claim 4 above.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. The Prior Art cited in the PTO-892 form includes prior art relevant to applicant’s disclosures related to systems for problem report, analysis, update deployment and user notifications.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MATTHEW J BROPHY whose telephone number is (571)270-1642. The examiner can normally be reached Monday-Friday, 9am-4:30pm.
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, Wei Zhen can be reached on 571-272-3708. 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.
MJB
5/29/2026
/MATTHEW J BROPHY/Primary Examiner, Art Unit 2191
Prosecution Insights