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 .
Information Disclosure Statement
The information disclosure statement provided filed on 02/03/2026 has been considered.
Status of Claims
The present application is being examined under the claims filed 01/27/2026. Claims 1-9 are pending. Claims 1-9 are rejected.
Response to Arguments
I. Applicant's arguments filed 01/27/2026 have been fully considered but they are not persuasive.
II. Regarding the 35 USC § 112 rejection of Claim 2, applicant argues that “communication protocols” relate to communication protocol related files, such as protocol-related configuration files, metadata files, or OS-level protocol definitions, therefore is the claim is not indefinite.
Examiner maintains that “communication protocols” themselves are not files. Applicant’s argument also recognizes that the claim is intended to reference “communication protocol related files,” (rem. 8). Because it is possible for an API to provide access to communication protocols directly (i.e., allow a system to send or receive data), the claim should reference that the API is explicitly providing access to communication protocol related files.
III. Regarding the 35 USC § 103 rejection of Claim 1, lines 13-16 applicant argues that Britton is a closed system and Britton does not teach or suggest exposing those mobile-device files to third-party developers through an application programming interface. Examiner respectfully disagrees, as Britton discloses developers being able to access and upload security patches to applications (Britton par. 85, patches for discovered vulnerabilities are developed by internal network 102).
Additionally, the secure charger accesses the mobile device files (Britton par. 111, the smart charger will have access to the application package (“APK”) files of every application) and uploads these files into a backend server (Britton FIG. 1 and par. 91, secure charger 124 reports the scan results to internal network 102; and Britton par. 53, scans will include non-private analysis data or statistics and analysis, for example, installed applications). Developers of the applications will have access to these files (Britton par. 24, application authors/publishers and services that provide the applications for download can connect to the remote location). Pousti is also utilized to teach an API with a higher degree of developer involvement.
IV. In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986).
While applicant argues that Britton, Brett, and Pousti each lack aspects of the claimed invention, the rejection of claims 1-9 are based on the combination of references.
V. Additionally, applicant argues the combination would merely result in “a charger capable of scanning and backing up a mobile device while communicating with a remote server,” (rem. 11), but not the API aspect of the claim. However, the instant application FIG. 1 shows the architecture of the smart charger 100, which is able to scan and back up device 200 and communicate with remote server 107. Developers use API 108 to connect to remote server 107. Therefore, the claimed invention of the instant application is “a charger capable of scanning and backing up a mobile device while communicating with a remote server.” In both the application and reference (See Britton FIG. 1, secure charger 124 connects to backend webserver pool 104), the charger is connected to the remote server and the API is provided via the remote server (Britton par. 24, application authors/publishers and services that provide the applications for download can connect to the remote location). This architecture is also supported in the claims, as claim 1 states “d) ….one remote computer/server having an operating software coupled to an API;”
VI. Regarding Claim 1, lines 13-22 applicant argues the instant application includes a dual-location and dual-environment execution model, which is absent from Britton, Brett, and Pousti. Examiner respectfully disagrees. Britton discloses “e2) …when stored in the mobile device, the dedicated applications are executable by the Operating System (OS) of said mobile device, alone, or in conjunction with said at least one processor and said one or more software modules or applications (Britton par. 85, patches may be uploaded to, and implemented in, the OS and applications of mobile smart device 128 [i.e., the patches are stored and executable by the OS on the mobile smart device]… preferably, the uploading of the patches will be done through secure charger 124).” Therefore, the mobile device may be used as the execution environment. Furthermore, applications are able to be downloaded from the internal network to run on the charger, using the charger as the execution environment (Britton par. 64, SD card 512 is for storing the OS, security analysis programs, and the on-device database. Security analysis programs include, but not limited to, software programs that are included in secure charger 500 or available for download from internal network 102), therefore the applications provided are dual-location and dual-environment.
Claim Objections
Claim 8 is objected to because of the following informalities:
Regarding Claim 8, line 4 recites an “and” after the second to last limitation. However, line 2 indicates the device is “one of the following.” Therefore, the claim is written in the alternative, but uses an “and” operator instead of an “or” operator. Because a device cannot be a smartphone, a wearable smartwatch and smart glasses, the claim will be interpreted as though the “or” operator was intended instead.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
Claim 2 is rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding Claim 2, line 4 recites the limitation “communication protocols” as a type of predetermined files (line 2). However, communication protocols are not a type of file, and it is therefore unclear what files the API would provide secured access to. In the interest of compact prosecution, it will be interpreted that the types of files include configuration files detailing communication protocols used by the device.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-9 are rejected under 35 U.S.C. 103 as being unpatentable over Britton et. al. (US 2013/0117854 A1) [previously cited] in view of in view of Brett et. al. (US 2014/0013428 A1) [In IDS] and Pousti et. al. (US 2009/0320050 A1)
Regarding Claim 1, Britton discloses a computerized charger for a mobile device (Britton FIG. 1, secure charger and malware/virus scanner 124 [also see par. 78 detailing device operations]), comprising:
a) a charging unit having an AC cord for charging the battery of said mobile device (Britton FIG. 5A and par. 63, electrical prongs 502 [also see par. 63, prongs can be replaced with other means for connecting the secure charger to a power source, e.g., a cable extending from the secure charger] are shown for connecting the secure charger to a wall socket; and par. 64, secure charger has power transformer 506 for converting AC power to DC power [see par. 65, mobile device charges through cable 518] [i.e., device receives AC power through a cable and outputs this power to charge the battery of the mobile device]);
b) a communication and power supply cable connected to a charging interface of said mobile device (Britton FIG. 5A and par. 65, mobile device is scanned [i.e., communication] and charges [i.e., power supply] through cable 518 [or see par. 78, secure charger verifies the integrity of the connected mobile smart device [i.e., communication] and charges the device [i.e., power supply]]);
c) at least one processor and associated memory, being capable of performing […] malware detection operations with respect to said mobile device (Britton FIG. 5A and par. 64, CPU 508 [i.e., processor] is for controlling all of the operations of the secure charger [see also FIG. 11 and par. 111, secure charger operation conducting a scan of mobile smart device 128 [i.e., mobile/computation device] for malware or other type of virus]; and par. 64, SD card 512 [i.e., associated memory] is for storing the OS, security analysis programs, and the on-device database);
d) a communication port, connected, via a communication channel (Britton FIG. 5 and par. 65, cable 518 extends from a connector [i.e., communication port] in housing of smart charger; and Britton par. 52, secure charger uses internet connection from the smart device to connect to the backend server 104 [i.e., communication channel]), to at least one remote computer/server having an operating software (Britton FIG. 1 and par. 71, scans of mobile smart devices are carried out and information is transmitted to, and received from, backend server 104 [i.e., remote server]; Britton par. 92, servers contain operating software that can be used by an administrator to monitor the system for problems, and perform investigations into identified problems and Britton par. 83, backend server handles queries from secure charger [i.e., also operating software]) coupled to an API (Britton par. 55, database 110 stores for each mobile smart device model it supports the software versions, baselines, and miscellaneous analysis information, e.g., recovery images; …database 110 is queried by secure charger 124 for information to do scan analysis [NOTE: APIs allow software components to communicate with each other via sets of definitions and protocols, which is the functionality described in regards to the internal network 102 and communications between the server 104 and the secure charger 124]); and
e) one or more software modules or applications, stored in said memory and run by said at least one processor (Britton FIG. 5A and par. 64, SD card 512 is for storing the OS, security analysis programs [see par. 64, security analysis programs include software programs that are included in secure charger], and the on-device database; and Britton FIG. 5A and par. 64, CPU 508 is for controlling all of the operations of the secure charger), wherein said operating software and said one or more software modules or applications are adapted to:
e1) provide secured access […] to predetermined files in said mobile device during charging periods of said mobile device (Britton par. 49, secure charger that charges the mobile smart device and while charging, performs forensic and behavior analysis of the mobile smart device), for allowing said application developers to create and store dedicated applications (Britton par. 111, the smart charger will have access to the application package (“APK”) files of every application; and Britton FIG. 1 and par. 91, secure charger 124 reports the scan results to internal network 102; and Britton par. 24, application authors/publishers and services that provide the applications for download can connect to the remote location);
e2) download via said communication port, one or more of said dedicated applications into said associated memory or into said mobile device (Britton par. 64, SD card [i.e., associated memory on mobile device] stores security analysis programs, which include software programs that are available for download from internal network 102 [i.e., dedicated applications]; or Britton par. 85, patches for discovered vulnerabilities [i.e., dedicated applications] are developed by internal network and downloaded from a backend server 102 to secure charger [see par. 64, downloads are stored on SD card of secure charger]), wherein, when stored in the mobile device, the dedicated applications are executable by the Operating System (OS) of said mobile device, alone, or in conjunction with said at least one processor and said one or more software modules or applications (Britton par. 85, patches may be uploaded to, and implemented in, the OS and applications of mobile smart device 128 [i.e., the patches are stored and executable by the OS on the mobile smart device]… preferably, the uploading of the patches will be done through secure charger 124);
Britton does not explicitly teach:
c) at least one processor and associated memory, being capable of performing backup and malware detection operations with respect to said mobile device;
e1) provide secured access via said API to predetermined files in said mobile device during charging periods of said mobile device, for allowing said application developers to create and store dedicated applications;
In the analogous art of a charger (Brett FIG. 2, power charger 80) capable of scanning mobile devices during charging (Brett par. 12, processor 82 executes management operations which may be guided, at least in part, by the control software in the first storage area; and par. 37-38, scan includes procedures for locating malware, trojans, cookies, viruses, spam, worms, and root kits; Brett par. 55, restoration, or back-up operations are performed during charging of the phone battery), Brett teaches:
at least one processor (Brett FIG. 2, processor 82) and associated memory (Brett FIG. 2, first and second storage areas), being capable of performing backup (Brett par. 42, backup operation to back up the data files of the electronic device 10 into the second storage area 84, which may be accessed at a later time to restore the device to a good status) and malware detection operations (Brett par. 34, monitoring operation may include sending a signal from the processor of the power charger to the device controller to request the device controller to perform a security scan), with respect to said mobile device (Brett par. 34, security scan determines the status of the device [i.e., mobile device]).
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Britton and Bret before him, before the effective filing date of the claimed invention, to combine Britton’s computerized charger with security scanning capabilities with Brett’s backup operations, the motivation being to implement the ability to restore the mobile smart device to a previous state in the case the device is compromised (Britton par. 90), and to perform this type of recovery without inconvenience and excessive costs to the user resulting from needing to the return the device to the manufacturer or hand to a technician for possible repair (Brett par. 2).
Britton in view of Brett does not explicitly teach:
e1) provide secured access via said API to predetermined files in said mobile device during charging periods of said mobile device, for allowing said application developers to create and store dedicated applications;
In the analogous art of providing a method for software development on devices Pousti teaches:
e1) provide secured access via said API to predetermined files in said mobile device during charging periods of said mobile device (Pousti par. 126, desktop API supports the building of applications that can store documents and files on the mobile desktop, read/write documents and files on the mobile desktop, set sharing properties of documents and files; and par. 132, a third party application will have read only access to files in certain location on the mobile desktop, application can then have read/write access to files in designated locations [i.e., secure access to predetermined files]) for allowing said application developers to create and store dedicated applications (Pousti par. 32, software developers can offer software products to the users of the mobile community 202; and Pousti par. 44, communications between the application developer and the mobile community can occur);
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Britton, Brett, and Pousti before him, before the effective filing date of the claimed invention, to combine modified Britton’s communications during a charging period between the charger and a remote server for delivering software and patches with Pousti’s API for simplified development and file access, the motivation being to provide information to support the software development and OS/application patches disclosed by Britton, while securely providing a third party application the ability to save, read, and write files that the application has a right to access (Pousti par. 11).
Regarding Claim 2, Britton in view of Brett and Pousti discloses the computerized charger according to claim 1, wherein the predetermined files in said mobile device are selected from the group of:
OS files (Britton par. 19 and 120, scan results will include a list of each application and the OS on mobile smart device 128; and par. 95, scan process is different based on OS);
communication protocols (Britton par. 86, scan checks for permissions granted [i.e., configuration] of application to read SMS and access Internet [i.e., communication protocols]); and
data files (Britton par. 111, the smart charger will have access to the application package (“APK”) files of every application; and Britton par. 86, application analysis is carried out by listing and downloading all the applications from the smart device to the charger).
As all of these file types are present on the device, they are all part of the group of files on the mobile device that are selected from. Pousti teaches selectively providing a third-party application the ability to save, read, and write files based on predetermined conditions (Pousti par. 126, the API is a set of routines, data structures, object classes and/or protocols provided by libraries and/or operating system services in order to support the building of applications that can store documents and files on the mobile desktop, read/write documents and files on the mobile desktop, set sharing properties of documents and files; and par. 132, a third party application will have read only access to files in certain location on the mobile desktop, such as the desktop of the mobile desktop, or community file folders). Therefore, it would be obvious that these files are in the group of files that would be considered when selecting files to share with developers.
Regarding Claim 3, Britton in view of Brett and Pousti discloses the computerized charger according to claim 1, wherein the communication and power supply cable is a USB or micro-USB cable (Britton par. 87, secure charger reboots mobile smart device 128 into a boot image that is uploaded over USB; and par. 65, cable 518 extends from housing 504 and has a connector at the end for connecting to a mobile smart device for transmitting information and charging).
[The disclosed means for secure charger to communicate with the mobile device is a cable. The boot image is uploaded from the smart charger to the mobile device via USB. Therefore, cable 518 is inferred to be a USB cable.]
Regarding Claim 4, Britton in view of Brett and Pousti discloses the computerized charger according to claim 1, wherein the services provided to the mobile device during charging (Britton par. 19, while charging the smart charger scans for malware and other viruses in the applications and the OS on the mobile smart device; and Brett par. 55, restoration, or back-up operations are performed during charging of the phone battery), are one or more of the following:
offline and online backup of files and applications (Brett par. 42, back-up operation may be performed to back-up the data, files, and or other information into the storage area of the charger [i.e., offline]; and Brett par. 52, operation to Transmit Backup Data in Power Charger to Website Storage [i.e., online]);
deep malware scanning for new viruses, the presence of attackers, spyware and
ransom ware;
scanning and analysis of files and logs, for the detection of attacks or malware (Britton par. 86, application analysis scan will inspect the applications and look for suspicious behavior [e.g. a piece of malware tries to disguise some of its files as images by changing the extension]);
data encryption;
data comparison (Britton par. 83, filesystem analysis includes hashing the files of the mobile device, and comparing the hashes against hashes from a previous scan);
data restoration (Brett par. 41, restoration operations may include file recovery functions that include recovery of deleted files or files located in bad sectors or regions in memory, and restoration of corrupted files);
connection to an application marketplace containing dedicated applications, developed for the mobile device by third-party developers; and
remote maintenance and repair applications using the physical connection between the smart charger and the mobile device (Britton par. 85, when patches for discovered vulnerabilities can be downloaded from a backend server 102 to secure charger 124; patches then may be uploaded to the OS and applications of mobile smart device).
Regarding Claim 5, Britton in view of Brett and Pousti discloses the computerized charger according to claim 1, wherein the communication channel is a wireless communication channel (Britton FIG. 5 and par. 65, cable 518 extends from a connector [i.e., communication port] in housing of smart charger; Britton par. 52, secure charger uses internet connection from the smart device to connect to the backend server 104 [i.e., wireless communication channel].
Alternatively, Britton discuses a standalone embodiment of a scanning device, which does not require the wired connection to the mobile device in order to access wireless connectivity with the network (Britton FIG. 7 and par. 75, wireless transceiver 716 [i.e., communication port] for bidirectional communications with mobile secure device 128 and par. 76, an embodiment with a 802.11x wireless access point would have its own Internet connectivity, and would connect to internal network 102 itself rather than connecting through mobile smart device 128 [i.e., scanner has its own a wireless communication channel]).
Therefore, it would have been obvious of one of ordinary skill in the art, having the teachings of Britton before him, before the effective filing date of the claimed invention, to incorporate the fully wireless embodiment of the communication between charger and the smart device, the motivation being to provide more mobility by wirelessly connecting to the mobile device (Briton par. 76).
Regarding Claim 6, Britton in view of Brett and Pousti discloses the computerized charger according to claim 1, being adapted to delete or quarantine suspicious detected files (Britton par. 126, if an application is not trusted, it may be removed [i.e., deleted] and a notification sent to the system user and/or system administrator).
Regarding Claim 7, Britton in view of Brett and Pousti discloses the computerized charger according to claim 1, being adapted to:
issue warnings and indications to the user regarding malicious files (Britton par. 90, if the results of the scans indicate that there are identified “compromises,” the user is alerted via LED lights (see FIGS. 5A and 5B), LCD (see FIGS. 6A and 6B), SMS, and/or email);
delete suspected files (Britton par. 126, if an application is not trusted, it may be removed [the files of the application are suspected and removed through application deletion]);
delete suspected files (Britton par. 126, if an application is not trusted, it may be removed [the files of the application are suspected and removed through application deletion]);
block the operation of suspected files (Britton par. 87, charger 124 will reboot mobile smart device 128 into a boot image that is uploaded over USB to boot loader, so if the OS is “compromised,” it cannot lie to secure charger 124 because the compromised OS is not running and cannot affect the scan [the suspected files in the compromised OS are blocked from running in the secure boot environment]);
clean malicious applications (Britton par. 126, if an application is not trusted, it may be removed [application is cleaned through removal]; alternatively, par. 85, provide patches to application that can prevent malware and exploits from accessing the OS or applications [application is cleaned through patching]); and
perform software updates (Britton par. 85, patches for discovered vulnerabilities [i.e., software updates] can be downloaded from a backend server 102 to secure charger 124; patches then may be uploaded to the OS and applications of mobile smart device).
Regarding Claim 8, Britton in view of Brett and Pousti discloses the computerized charger according to claim 1, wherein the mobile device is one of the following:
a smartphone (Britton par. 81, the initial mobile smart phone device OS for the smart mobile device is stored; Britton par. 95, mobile smart device may be a smartphone);
a wearable smartwatch; or
smart glasses.
Regarding Claim 9, Britton in view of Brett and Pousti discloses the computerized charger according to claim 1, wherein the dedicated applications include one or more of the following:
key applications stored on the smart-charger to authenticate e-wallet transactions and secure payments;
saving capability of personal or sensitive information external to the mobile device;
key storage applications for implementing secure electronic wallets, and Non-Fungible Tokens (NFTs);
authentication and identification applications (Britton par. 125, the segmented portion of scan database 112 will include application/application publisher signature information so the system will be prepared to verify applications);
biometric applications, based on data received from biometric sensors that reside on the smart charger; and
an application ecosystem for synchronization between different mobile devices being connected to the smart charger, according to the user's profile and other predefined parameters.
Conclusion
THIS ACTION IS MADE FINAL. 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 COLE JIAWEI WENTZEL whose telephone number is (703) 756-4762. The examiner can normally be reached 9:30am-5:30pm (Mon-Fri).
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Andrew Jung can be reached on (571) 270-3779. 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.
/C.J.W./Examiner, Art Unit 2175
/ANDREW J JUNG/Supervisory Patent Examiner, Art Unit 2175
Prosecution Insights