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 . 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.
Claims 5, 8, 14-16, 19-20 are cancelled.
Claims 1, 9, and 10 are currently amended.
Claims 1-4, 6-7, 9-13 and 17-18 are pending.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1, 4, 6, 9, 10, 13, and 17 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.
Applicant’s arguments, see 9, filed 09/05/2025 with respect to claim 10 have been fully considered and are persuasive. The rejection under 35 U.S.C. 101 of 09/05/2025 has been withdrawn.
Applicant's arguments filed 11/21/2025 have been fully considered but they are not persuasive.
Applicant argues:
Further, the contents recorded in 0047 of Adika are merely a further elaboration on "Identifying a user selection indicative of the one or more GUI elements" and how to achieve "Identifying".
Obviously, Adika teaches nothing about "monitoring an operation onto the preset HTML5 resource read-only protection zone"; and further, the "write operation" of Adika is edited through the GUI of a client terminal, while the "write operation" of in the present application is configured for writing data of a local HTML5 resource package into the HTML5 resource read-only protection zone to install a HTML5 application (as required in claims 1, 9 and 10 of the present application as now presented).
Examiner respectfully disagree, Adika disclose identifying GUI elements of a client terminal and to support “How to Identifying” Adika disclose in paragraph [0078], The quick edit module 214 may also identify the user interaction by monitoring the user interface 208 [0075], The user interaction may include, for example, a double click of the pointing device left button, a single click of the pointing device right button, a single click of the pointing device left button, a hover of the pointing device cursor, a multi-touch on a touch screen and/or the like”.
Examiner does not need to cite this portion explicitly because a person of ordinary skill in the art (POSITA) would generally understand that identifying GUI elements can be accomplished by monitoring user interactions, even if that specific step is not explicitly cited in a patent description. Therefore “Identifying” process can be achieved.
Additionally applicant argues,
“In contrast, ACCIICMEZ et al further disclosed, see paragraph 0092: ".At 504, an operating system service request is sent to the operating system when the web browser (including the plugs-in, if appropriate) needs to access a resource. At 506, an indication is received as to whether the access is permitted. This indication is received from the operating system, and is based upon an access control security policy using a stored security context for the resource and a current context of the instance of the web browser. At 508, it is determined if the indication permits access or not. If so, then at 510, the web browser accesses the resource. Otherwise, at 512, error handling is performed to deal with the rejection of the access of the resource."
That is, ACCIICMEZ et al disclosed an access control security policy is applied based upon the security context and based upon information regarding the instance of a web browser, wherein the security policy grants access to the resource if a property or properties of the security context match a property or properties of the instance of the web browser. This applying of the security policy may be performed by the security module.
In contrast, as recorded in paragraph 0033 of Li et al: "the Application security module 306 is configured to perform security verification of browser-based application 304 on the client computing device 102. The Application security module 306 can be presented as an independent module, or in some embodiments, as a browser plugin."
Applicant should submit an argument under the heading “Remarks” pointing out disagreements with the examiner’s contentions. Applicant must also discuss the references applied against the claims, explaining how the claims avoid the references or distinguish from them. Applicant need to point out which claim limitation does not teach by the cited prior art and explain how art fails to teach certain claim limitations.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim 1, 9 and 10 are 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.
The claim recites, inter alia, “presetting a HTML5 resource read-only protection zone in a storage space of an internal storage medium of a terminal device.” It is unclear what structure or specific storage arrangement is encompassed by the coined term “HTML5 resource read-only protection zone,” and what specific act(s) constitute “presetting” such a zone. The specification describes the HTML5 resource read-only protection zone only in functional terms (e.g., that it is located in internal storage and that non-read operations by non-system authority processes are restricted, optionally via a system firewall) without clearly identifying any particular file-system structure, partition, directory, access control mechanism, or other objective boundaries that would allow one of ordinary skill in the art to determine, with reasonable certainty, whether a given storage configuration is or is not an “HTML5 resource read-only protection zone.”
In the absence of a clear definition in the specification, a person of ordinary skill in the art cannot ascertain the metes and bounds of “presetting a HTML5 resource read-only protection zone in a storage space of an internal storage medium of a terminal device,” because it is unclear (i) what minimum technical features or constraints are required for a storage area to qualify as such a “protection zone,” and (ii) what operations are required to “preset” the zone as opposed to merely using an existing storage location. Accordingly, the scope of the claim is not reasonably certain, and the claim is indefinite under 35 U.S.C. 112(b).
For the purposes of compact prosecution, for this office action, the examiner hereby interpret this limitation to mean: "defining in advance, within the terminal device’s internal storage (as opposed to external storage), a specific storage area that is designated for storing HTML5-related resources and is configured to be read-only (i.e., not subject to modification)"
Dependent claims 2-4, 6-7 and 11-13 and 17-18:
Claims that depend on rejected base claims (i.e. claims 1, 9 and 10) inherit by the nature of their dependency all rejections that are applied to their corresponding base claims. Thus, claims 2-4, 6-7 and 11-3 and 17-18 are, in addition to any separate rejection disclosed above, also rejected using the same grounds of rejection as indicated in the rejection of their corresponding base claims above.
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, 4, 6, 9, 10, 13, 17 are rejected under 35 U.S.C. 103 as being unpatentable over Adika et al (U. S. PGPub. No. 2018/0173386 A1) (hereinafter “Adika”), in view of ACCIICMEZ et al (U. S. PGPub. No. 20110138174 A1) (hereinafter “ACCIICMEZ”) and Li et al (U. S. PGPub. No. 2014/0096241 A1) (hereinafter “Li”); in view of Fahrny et al. (U. S. PGPub. No. 2017/0244729 A1) (hereinafter “Fahrny”); and further in view of Challener et al. (U. S. Pat. No. 7,581,252 B2) (hereinafter “Challener”)
Regarding Claim 1, Adika teaches:
monitoring an operation on the preset HTML5 resource read-only protection zone through a system authority service (Adika: Examiner interpreting that application page as preset HTML5 resource because an application page can be considered an HTML resource especially when referring to a "single-page application" (SPA) where the entire application interface is essentially one HTML page that is dynamically updated based on user interactions.
Therefore Adika teaches in para [0047], The user context which is the content presented in the application page is first parsed to identify the GUI element(s) present in the user context. The identified GUI element(s) are further analyzed to identify one or more editing characteristics of a data record represented by each of the identified GUI elements, for example, whether the data record is editable, which of the data record's attribute(s) may be edited and what user access permission applies to each editing operation. Furthermore, the GUI elements presenting editable data records may be marked to indicate to the user which of the respective data records is editable.
allowing to execute a write operation when the operation on the preset HTML 5 resource read-only protection zone is the write operation executed by a system authority process (Adika: [0047], resources management applications, organization applications and/or the like, may typically present a high-level view of a plurality of data records and/or parts thereof displayed as read-only GUI elements, i.e., the GUI elements are presented in non-editable areas (=read-only protection zone) of the user context….The quick editing may editing(=allowing to perform write operation) the GUI element(s) directly from the application's read-only view in which the GUI element(s) are typically displayed in the non-editable area(s))
wherein the write operation is configured for writing data of a local HTML5 resource package into the HTML5 resource read-only protection zone to install a HTML5 application (Adika: [0067 ], provides in case of the local application 210C, the quick edit module 214 may apply the edit operations directly to the local application);
allowing to execute a read operation when the operation on the preset HTML5 resource read-only protection zone is the read operation executed by (Adika: [0079] As shown at 108, based on the identifier information constructed for the data record comprising the attribute(s) presented by the GUI element(s) selected by the user 250, the quick edit module 214 may render, in the read-only area of the current page, an editing GUI element associated with one or more of the selected GUI element(s)….Before rendering the editing GUI element, the quick edit module 214 may check a privilege value of the access permission attribute for the data record associated with the selected GUI element(s) to verify the user 250 is privileged for editing the data record(s). The quick edit module 214 may render the editing GUI element in case the user 250 is privileged for editing the data record(s).);
Adika does not explicitly disclose:
monitoring data accessed by a built-in browser kernel of the HTML5 application when the HTML5 application is installed.
restricting an access operation of the built-in browser kernel when the data accessed by the built-in browser kernel is data of a non-HTML5 resource read-only protection zone.
However, ACIICMEZ teaches:
monitoring data accessed by a built-in browser kernel of the HTML5 application when the HTML5 application is installed (ACIICMEZ: [0053], The kernel then asks the security modules, prior to accessing internal objects, for access decisions by invoking the appropriate hook function. The security modules can analyze the access requests in these hook functions and either permit or prohibit the access. The kernel is module-agnostic, but provides a powerful framework for modules to operate seamlessly. [0092], At 500, a plug-in to the web browser may be installed. It should be noted that this plug-in is optional, but if the plug-in is installed, it has access to all the same resources as the web browser itself, and thus has the same security issues);
restricting an access operation of the built-in browser kernel when the data accessed by the built-in browser kernel is data of a non-HTML5 resource read-only protection zone (ACIICMEZ: [0092], At 506, an indication is received as to whether the access is permitted. This indication is received from the operating system, and is based upon an access control security policy using a stored security context for the resource and a current context of the instance of the web browser. At 508, it is determined if the indication permits access or not. If so, then at 510, the web browser accesses the resource. Otherwise, at 512, error handling is performed to deal with the rejection of the access of the resource);
It would be obvious to a person having ordinary skill in the art, before the effective filing date of the invention, to modify Adika’s method of rendering the page according to users privileges by verifying the user’s privileges for editing/reading the data record(s) and allow to edit read-only data by applying ACIICMEZ’s method of analyzing the access requests in these hook functions and either permit or prohibit the access, in order to security module can apply access control security policies to such web browser access attempts (ACIICMEZ: [0027]). The motivation is to prevent malicious or accidental misuse of such resources (ACIICMEZ: [0014]).
The combination of Adika in view of ACIICMEZ does not explicitly disclose:
wherein non-system authority process comprises the HTML5 application;
However, in an analogous art, Li teaches:
(Li: [0033] The application security module (=examiner interpreting application security module as a non-system authority) 306 is configured to perform the security verification of the browser-based application 304 on the client computing device 102) ;
wherein non-system authority process comprises the HTML5 application (Li: [0001], HTML5 allows developers to integrate active code into a webpage that is able to execute inside the browser of the client device. [0032] The browser 302 of the client computing device 102 may be used to request and interpret the browser-based application 304 from the web server 106. In some embodiments, the browser-based application 304 may be embodied as a Hypertext Markup Language 5 (HTML5) application. [0033] The application security module (=examiner interpreting application security module as a non-system authority) 306 is configured to perform the security verification of the browser-based application 304 on the client computing device 102);
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Adika in view of ACIICMEZ by applying the well-known technique as disclosed by LI of , the browser-based application 304 may be embodied as a Hypertext Markup Language 5 (HTML5) application. The motivation is to enabling developers to incorporate increased features and capabilities into browser-based applications. For example, HTML5 allows developers to integrate active code into a webpage that is able to execute inside the browser of the client device (Li: [0001]).
The combination of Adika in view of ACIICMEZ and Li does not explicitly disclose:
wherein before writing the local HTML5 resource package into the HTML5 resource read-only protection zone, an authenticity and integrity of the local HTML5 resource package is verified;
and after writing the local HTML5 resource package into the HTML5 resource read- only protection zone, the authenticity and integrity of the HTML5 resource read-only protection zone is periodically self-verified.
However, in an analogous art, Faheny teaches:
wherein before writing the local HTML5 resource package into the HTML5 resource read-only protection zone (Faheny: [0020], The intrusion detection agent may determine which file system reads and writes are allowed. [0041], the intrusion detection agent may periodically perform a hash function on the web browser application and compare the resulting hash value against a locally stored authentication code to determine whether the browser's execution code has been tampered with and/or modified. [0057], Since the security processor 304 on device 302a may repeatedly validate each process on the device 302a to check at periodic time intervals whether each application process is still valid and has not been corrupted, the security processor 304 may use the updated hash function and authentication code to repeatedly validate the updated application process instead of using the old hash function and authentication code that were used to validate the application before the application was updated), an authenticity and integrity of the local HTML5 resource package is verified (Faheny: [0062], The intrusion detection agent 402 may also validate each application process executing on the computing device periodically or in response to a specific event by instructing the runtime validation engine 404 to authenticate and verify the integrity of the application process….[0063] In some embodiments, the runtime validation engine 404 may validate a standard process 416 by authenticating and verifying its data integrity to ensure that standard process 416 has not been comprised in a security breach. The runtime validation engine 404 may periodically run a cryptographic hash function on standard process 416 to check its validity….Upon successful verification, the runtime validation engine 404 may transmit a message to the intrusion detection agent 402 that the application process, process trusted entity, or kernel module it was verifying is valid);
and after writing the local HTML5 resource package into the HTML5 resource read- only protection zone (Fahrny: [0063], The runtime validation engine 404 may also append a signature to the application process, process trusted entity, or kernel module indicating its validity. Such a signature may be valid for a certain duration of time, after which the application process, process trusted entity, or kernel module may need to be validated again (=after writing operation) before it performs further operations on the computing device), the authenticity and integrity of the HTML5 resource read-only protection zone is periodically self-verified (Fahrny: [0041], the intrusion detection agent may periodically perform a hash function on the web browser application and compare the resulting hash value against a locally stored authentication code to determine whether the browser's execution code has been tampered with and/or modified…[0056], each device may perform application process validation on its own periodically…).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Adika in view of ACIICMEZ and Li by applying the well-known technique as disclosed by Fahrny of periodically authenticating and verifying integrity in order to determining whether the browser’s execution code has been tempered with and/or modified. The motivation is to improve security monitoring to prevent security breaches (Fahrny:[0001]).
The Adika in view of ACIICMEZ, Li and Fahrny does not explicitly disclose:
presetting a HTML5 resource read-only protection zone in a storage space of an internal storage medium of a terminal device.
However, in an analogous art, Challener teaches:
presetting a HTML5 resource read-only protection zone in a storage space of an internal storage medium of a terminal device (Challener: [Col 4, lines 1-5], The storage device is subdivided into a protected area and the scan area. The protected area is securely configurable (=presetting) between a normal read-only state (=read-only protection zone) and a writeable state. The configuration (=presetting) of the areas is under the control of a security system having a secure memory which is inaccessible to code executed under an operating system. [Col 12, lines 1-4], The files dates of the files in the protected areas 202 can be trusted since the protected areas are maintained in a read-only access mode during normal operation and can only be altered through authenticated procedures)
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Adika in view of ACIICMEZ, Li and Fahrny by applying the well-known technique as disclosed by Challener of configuring protected area as “read-only zone”. The motivation is to prevent from viruses and invalid or corrupt registry entries by scanning unaltered files or storage areas are scanned against a subset of virus definition (Challener: [Abstract]).
Regarding Claim 4, Adika in view of ACIICMEZ, Li and Fahrny, Challener teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein before allowing to execute a write operation when the operation is the write operation executed by a system authority process, the method comprises: (Li: [0033], In some embodiments, the application security module 306 may forward the request to the cloud service system 108 for analysis before permitting the browser 302 to execute (=allowing to execute) the browser-based application 304 or download any portion of the browser-based application 304).
verifying an installation package of the HTML5 application (Li: [0029] The application verification module 204 is configured to verify the security of the browser-based application 304 itself. To do so, in some embodiments, the application verification module 204 may retrieve application validation data from the local database 118 of the cloud service system 108 and/or retrieve the application validation data from the cloud resources 110. The application validation data may be embodied as trusted source code that the application verification module 204 may compare with the browser-based application 304 code. [0035], the cloud service system 108 may receive, in block 404, metadata from the client computing device 102 indicating the location of the browser-based application 304 and download the browser-based application 304 from the web server 106 at the specified location);
verifying a local HTML5 resource package when downloading the local HTML5 resource package (Li: [0029], The application validation data may be embodied as trusted source code that the application verification module 204 may compare with the browser-based application 304 code. In such embodiments, the application verification module 204 may compare the trusted source code to the code of the browser-based application to verify the security of the browser-based application 304);
and allowing to execute the write operation when both the verification of the installation package of the HTML5 application and the local HTML5 resource package are passed (LI: [0033] provides for the application security module 306 may forward the request to the cloud service system 108 for analysis before permitting the browser 302 to execute (=allow to execute) the browser-based application 304 or download any portion of the browser-based application 304).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Adika in view of ACIICMEZ and Challener by applying the well-known technique as disclosed by Li of the application verification module compare the trusted source code to the code of the browser-based application to verify the security of the browser-based application. The motivation is to enabling developers to incorporate increased features and capabilities into browser-based applications. For example, HTML5 allows developers to integrate active code into a webpage that is able to execute inside the browser of the client device (Li: [0001]).
Regarding Claim 6, Adika in view of ACIICMEZ, Li and Fahrny, Challenger teaches:
The method of claim 1 (see rejection of claim 1 above),
wherein the data of the non-HTML5 resource read-only protection zone comprises: data with access paths being different from that of the data in the HTML5 resource read- only protection zone (Adika: Examiner broadly interpreting that URL of a certain webpage which can be a HTML5 page or non-HTML5 page which are different from each other. Therefore Adika disclose in para [0050], navigations required to follow in order to perform the editing operations...)
and data with access paths existing outside the HTML5 resource read-only protection zone and comprising relative paths of the data in the HTML5 resource read-only protection zone (Adika: Examiner broadly interpreting that of a certain webpage which can be a HTML5 page or non-HTML5 page which are different from each other. Therefore Adika disclose in para [0088], assuming one of the attributes of the a certain data record is a link to a certain webpage…the quick edit module 214 may render…the of a certain webpage. The quick edit module 214 may further monitor interaction of the user 250 with the presented link, for example, a right click of the pointing device on the link attribute presented in the editing GUI element to open the pointed specific webpage (=specific webpage can be non-html5 or html5 page) in a window of a web browser such as the web browser 212A).
Regarding Claim 9, this claim contains identical limitations found within that of claim 1
above albeit directed to a different statutory category (device medium). For this reason, the same grounds of rejection are applied to claim 9.
Regarding Claim 10, Adika teaches:
wherein the computer-readable storage medium stores a computer program, when the computer program is executed by a processor (Adika: [0052], a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present invention).
This claim contains identical limitations found within that of claim 1 above albeit directed to a different statutory category (Computer readable storage medium). For this reason, the same grounds of rejection are applied to claim 10.
Regarding Claim 13, this claim contains identical limitations found within that of claim 4
above albeit directed to a different statutory category (device medium). For this reason, the same grounds of rejection are applied to claim 13.
Regarding Claim 17, this claim contains identical limitations found within that of claim 6
above albeit directed to a different statutory category (device medium). For this reason, the same grounds of rejection are applied to claim 17.
Claim(s) 2 and 11 are rejected under 35 U.S.C. 103 as being unpatentable over Adika et al (U. S. PGPub. No. 2018/0173386 A1) (hereinafter “Adika”), and further in view of ACCIICMEZ et al (U. S. PGPub. No. 20110138174 A1) (hereinafter “ACCIICMEZ”), Li et al (U. S. PGPub. No. 2014/0096241 A1) (hereinafter “Li”), Fahrny et al. (U. S. PGPub. No. 2017/0244729 A1) (hereinafter “Fahrny”) and Challener et al. (U. S. Pat. No. 7,581,252 B2) (hereinafter “Challener”); and further in view of Perry et al (U. S. Pat. No. 8732474 B1) (hereinafter “Perry”) .
Regarding Claim 2, Adika in view of ACIICMEZ, Li and Fahrny, Challener teaches:
The method of claim 1 (see rejection of claim 1 above),
The combination of Adika in view of ACIICMEZ and Li does not explicitly disclose:
verifying the local HTML5 resource package before executing the write operation; and backing up and saving the local HTML5 resource package in a preset HTML5 resource backup zone when the verification of the local HTML5 resource package is passed.
However, in an analogous art, Perry teaches:
verifying the local HTML5 resource package before executing the write operation (Perry: [Col 2, lines 32-37], (10) The computer- implemented method may include, prior to launching the sandboxed sub-process: extracting a public key from the header; and validating (verifying) a digital signature of the compressed, archived file using the public key. If validation of the digital signature is successful, installation of the browser extension may continue.
and backing up and saving the local HTML5 resource package in a preset HTML5 resource backup zone (Perry: [Col 2, lines 22-24], a temporary file directory for use by the sandboxed process and copying the browser extension installation package to the temporary file directory. [Col 9, lines 25-34], (35) At block 410, the method 400 includes creating a temporary file directory, which may also be referred to as designating temporary file storage space 230 in the corresponding computing system's file system. In the method 400, the temporary file directory/file space 230 is accessible to the sandboxed sub-process 220. At block 415, the method 400 includes copying (or placing) the browser extension installation package 100 to (in) the temporary file directory/file space 230) when the verification of the local HTML5 resource package is passed (Perry: [Col 2, lines 40-45], Unpacking the compressed, archived file into the plurality of constituent files of the browser extension may include determining whether unpacking of the compressed, archived file completed successfully. If unpacking of the compressed, archived file completed successfully, installation of the browser extension may continue);
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Adika in view of ACIICMEZ, Li and Fahrny, Challener by applying the well-known technique as disclosed by Perry of copying the browser extension installation package. The motivation is to prevent some of the types of data files used in browser extensions (e.g., image files and JSON objects) may be used as a vehicle for malicious acts, such as placing persistent malware (malicious software) on a user's computing system (Perry: Col 5, lines 55-58]).
Regarding Claim 11, this claim contains identical limitations found within that of claim 2
above albeit directed to a different statutory category (device medium). For this reason, the same grounds of rejection are applied to claim 11.
Claim(s) 3 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Adika et al (U. S. PGPub. No. 2018/0173386 A1) (hereinafter “Adika”), and further in view of ACCIICMEZ et al (U. S. PGPub. No. 20110138174 A1) (hereinafter “ACCIICMEZ”) and Li et al (U. S. PGPub. No. 2014/0096241 A1) (hereinafter “Li”), Fahrny et al. (U. S. PGPub. No. 2017/0244729 A1) (hereinafter “Fahrny”) and Challener et al. (U. S. Pat. No. 7,581,252 B2) (hereinafter “Challener”), Perry et al (U. S. Pat. No. 8732474 B1) (hereinafter “Perry”); and further in view of Montulli et al (U. S. Pat. No. 8977598 B2) (hereinafter “Montulli”)
Regarding Claim 3, Adika in view of ACIICMEZ, Li, Fahrny, Challener and Perry teaches:
The method of claim 2 (see rejection of claim 2 above),
wherein after backing up and saving the local HTML5 resource package in a preset HTML5 resource backup zone when the verification of the local HTML5 resource package is passed, the method further comprises (Perry: [Col 10, lines 57-67], If the unpacking is successfully completed, the method 500 continues installation of the corresponding browser extension at block 525 (block 445 in FIG. 4). At block 530, the method 500 includes determining whether the validation of a header of a browser extension installation package at block 445 (which may be implemented using the method 600) is successful. If the validation is successful, the method 500 continues installation of the corresponding browser extension at block 535 (block 450 in FIG. 4):
comparing the local HTML5 resource package backed up and saved in the HTML5 resource backup zone with the HTML5 resource package written in the HTML5 resource read- only protection zone when the verifying of the local HTML5 resource package backed up in the HTML5 resource backup area is passed (Perry: [Col 2, lines 55-65], Validating the header may include: verifying that a size of the header matches an expected header size; verifying that the header includes a properly located browser extension installation package identifying code; verifying that the header includes a properly formed and properly located version field; verifying that a size of a public key included in the browser extension installation package matches an expected public key size; verifying that a size of a digital signature of the browser extension installation package matches an expected digital signature size; and/or verifying that a format of the public key matches an expected public key format);
and notifying an operating system to trigger protection for system operation and using when the local HTML5 resource package backed up and saved in the HTML5 resource backup zone is inconsistent with the HTML5 resource package written in the HTML5 resource read-only protection zone (Perry: [Col 13, lines 41-54], However, if the parsing operation of block 910 occurs in the sandboxed sub-process 220, any harmful effects that could result from attempting to parse a malicious or poorly formed JSON object may be avoided. For example, as was discussed above with respect to block 550, if the parsing at block 910 fails to complete successfully, installation of a browser extension from an associated browser extension installation package may be halted, canceled and/or aborted, such as at blocks 550 and 560 of FIG. 5. In this situation, appropriate notifications may be made, such as notifying a user that an error occurred during installation of the browser extension. In an example embodiment, the error notification may include an assigned error code and/or a narrative description of the error).
Furthermore, the above cited combination of Adika in view of ACIICMEZ, Li, Fahrny and Perry does not explicitly disclose:
verifying the local HTML5 resource package backed up and saved in the HTML5 resource backup zone every preset time period,
However, in an analogous art, Montulli teaches:
verifying the local HTML5 resource package backed up and saved in the HTML5 resource backup zone every preset time period (Montulli: [abstract]: storing a local copy of the replicated client data on a local data storage device coupled to the computer. [Col 2, lines 10-16], (9) Most backup systems operate by having the network administrator identify a time of day during which little or no network activity occurs. During this time the network administrator turns the network over to a backup system and the data files stored on the computer network are backed up, file by file, to a long-term storage medium, such as a tape backup system. Typically, the network administrator will back up once a week, or even once a day(=preset time period), to ensure that the backup files are current(=verifying backup). [Col 2, lines 43-55], systems and methods are disclosed for improved Backup/Replication Performance via Locally Distributed Change Detection. Traditional backup systems talk to a central server which has a catalog of what has been backed up. The instant client software 10, as a replication solution, needs to rapidly identify what files have changed. By making the simplifying assumption that all writes to the given replication destination sub-tree are going through the client software, the Manifest files are a local representation of what the remote (replicated/back end) state was. Therefore, the client software only has to compare the defined job to the manifest (avoiding network round trip) to determine what needs to be transmitted to the back end);
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Adika in view of ACIICMEZ, Li, Fahrny, Challener and Perry by applying the well-known technique as disclosed by Montulli of during predetermined time the network administrator turns the network over to a backup system and the data files stored on the computer network are backed up, file by file, to a long-term storage medium, such as a tape backup system. The motivation is to provide disaster recovery and mainlining back up files for servers on a computer network (Montulli: [Col 1, lines 6-8]).
Regarding Claim 12, this claim contains identical limitations found within that of claim 3
below albeit directed to a different statutory category (device medium). For this reason, the same grounds of rejection are applied to claim 12.
Claim(s) 7 and 18 is rejected under 35 U.S.C. 103 as being unpatentable over Adika et al (U. S. PGPub. No. 2018/0173386 A1) (hereinafter “Adika”), and further in view of ACCIICMEZ et al (U. S. PGPub. No. 20110138174 A1) (hereinafter “ACCIICMEZ”) and Li et al (U. S. PGPub. No. 2014/0096241 A1) (hereinafter “Li”), Fahrny et al. (U. S. PGPub. No. 2017/0244729 A1) (hereinafter “Fahrny”) and Challener et al. (U. S. Pat. No. 7,581,252 B2) (hereinafter “Challener”); and further in view of ZONG (U. S. PGPub. No. 2017/0371888 A1) (hereinafter “Zong”).
Regarding Claim 7, Adika in view of ACIICMEZ, Li and Fahrny and Chellener teaches:
The method of claim 1 (see rejection of claim 1 above),
The combination of Adika in view of ACIICMEZ, Li and Fahrny does not explicitly disclose:
wherein restricting an access operation of the built-in browser kernel comprises: restricting the access operation of the built-in browser kernel by means of URI interception, URL interception or file handle interception.
However, in an analogous art, Zong teaches:
wherein restricting an access operation of the built-in browser kernel comprises (Zong: [0035] Step 204: intercepting and suspending the webpage access request. [0052] Step 214: abandoning the webpage access request in the Webkit kernel webpage subprocess. [0081] Step 318: abandoning the webpage access request in the IE kernel webpage subprocess. [0100] In conclusion, a webpage access request failed in advertisement resource verification may be directly abandoned, and thus is not suitable for intercepting advertisements hidden in a normal webpage content. Therefore, advertisement content verification needs to be performed on a webpage access request succeeded in advertisement resource verification to prevent the webpage access request from hiding in a normal webpage content and thus being unable to intercept a URL, thereby improving accuracy in advertisement interception):
restricting the access operation of the built-in browser kernel by means of URI interception, URL interception or file handle interception (Zong: [0026] Step 104: intercepting and suspending the webpage access request, wherein the webpage access request comprises a webpage address information URL. [0027] No matter the IE kernel webpage subprocess or the Webkit kernel webpage subprocess in the dual-kernel browser loads the webpage information according to the webpage access request, the webpage access request is intercepted and suspended, that is, the webpage access request is intercepted. The webpage access request includes a webpage address information URL (Uniform Resource Locator. [0030] In conclusion, when the dual-kernel browser sends a webpage access request to load corresponding webpage information using the IE kernel webpage subprocess and/or the Webkit kernel webpage subprocess, the webpage access request is intercepted and suspended, so that the webpage subprocess is prevented from directly loading the webpage information returned based on the webpage access request. [0108], The webpage access request failed in verification is directly abandoned, and the webpage information of the webpage access request is not returned to the requested webpage subprocess).
A person having ordinary skill in the art, before the effective filing date of the invention, would have found it obvious to modify Adika in view of ACIICMEZ, Li and Fahrny, Challener by applying the well-known technique as disclosed by Zong of abandoning the webpage access request in the IE kernel webpage subprocess. The motivation is to facilitate users browsing webpages, dual-kernel browsers emerge to parse and display different webpages using different kernels (Zong: [0003]).
Regarding Claim 18, this claim contains identical limitations found within that of claim 7
above albeit directed to a different statutory category (device medium). For this reason, the same grounds of rejection are applied to claim 18.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Refer to PTO-892, Notice of References Cited for a listing of analogous art.
CHUN et al. (U. S. PGPub. No. 2016/0320994 A1): Systems, methods, and computer programs are disclosed for providing a heterogeneous system memory in a portable communication device. One system comprises a system on chip (SoC) coupled to a nonvolatile random access memory (NVRAM) and a volatile random access memory (VRAM). The SoC comprises an operating system for mapping a heterogeneous system memory comprising the NVRAM and the VRAM. The operating system comprises a memory manager configured to allocate a first portion of the NVRAM as a block device for a swap operation, a second portion of the NVRAM for program code and read-only data, and a third portion of the NVRAM for operating system page tables. The VRAM is allocated for a program heap and a program stack.
Roach (U. S. PGPub. No. 2005/0234912 A1): A method includes invoking a computer application that operates on a computer that is capable of data communication with a dealer management system. The computer includes a software module with at least one control component for interfacing the computer application with the dealer management system. The computer application includes a data interface for receiving an identifier that is associated with data stored in the dealer management system. The identifier is entered into the computer application using the data interface and provided to the control component. The control component is operable to execute instructions for extracting at least a portion of the data associated with the identifier from the dealer management system, wherein the data is extracted in real-time from a database layer of the dealer management system.
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 RUPALI DHAKAD whose telephone number is (571)270-3743. The examiner can normally be reached M-F 8:30-5:30.
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, Alexander Lagor can be reached at 5712705143. 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.
/R.D./ Examiner, Art Unit 2437
/ALEXANDER LAGOR/ Supervisory Patent Examiner, Art Unit 2437