DETAILED ACTION
A. This action is in response to the following communications: Transmittal of New Application filed 09/03/2024.
B. Claims 1-8 and 15-16 remains pending.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-8 and 15-16 are rejected under 35 U.S.C. 101 because the claimed invention is directed to certain methods of organizing human activity without significantly more. The claim(s) 1 and 15-16recite(s) “determining a second list based upon a first list”, grouping of abstract ideas. The mere nominal recitation of a generic user interface processed and interacted with by means of a computer with processor does not take the claim out of the “certain methods of organizing human activity” grouping. Thus, the claim recites an abstract idea.
This judicial exception is not integrated into a practical application because the claim as a whole merely describes how to generally “apply” the concept of storing and updating information about installed applications in a computer environment. The claimed “method”, “device”” and “medium” are recited at a high level of generality and are merely invoked as tools perform records update process. Even considered in combination, simply implementing the abstract idea on a generic computer with storage devices recited at a high level of generality is not a practical application of the abstract idea.The limitation determining a second list, determining wherein the first application is a rogue application and replacing icons on a generic user interface executed by a generic computer, as drafted, is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting “by a processor/interface,” nothing in the claim element precludes the step from practically being performed in the mind. For example, but for the “by a processor” language, “in response to receiving” in the context of this claim encompasses the user manually organizing data.
The claim does not include additional elements that are sufficient to amount to the significantly more than the judicial exception because as noted previously, the interface, storage, processors individually and in combination merely describe how to generally “apply” the concept of updating records in a computer environment. The same applies here. (MPEP 2106.05(d). Thus, even when viewed as a whole, nothing in the claims adds significantly more (i.e. an inventive concept) to the abstract idea.
The claim is ineligible.
Claims 2-8 do not include elements that amount to significantly more than the abstract idea and are also rejected under the same rational.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-8 and 15-16 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Jang, Min et al. (US Pub. 2023/0161872 A1), herein referred to as “Jang”.
As for claims 1 and 15-16, Jang teaches. A visualization method and corresponding device of 15 and medium of 16 for an application icon, applied to an electronic device, wherein the method comprises:
determining a second list based on a first list in a preset condition, wherein the first second list comprises all applications installed on the electronic device (par. 52 an allow list is a list of trusted applications on the device; par. 82 The processor 120 may obtain a list of all applications installed on the electronic device through a package management module (e.g., the package management module 220 of FIG. 2 ) and analyze a package setting file (e.g., packages.xml) to identify applications classified as an untrusted application among all applications), the second list comprises a non- system application whose installation source is not an application market in all the applications, and the second list comprises a first application (par. 50 the electronic device 101 may classify the source of the application 146 according to a source type and inform a user of a risk of the untrusted application (e.g., a risk of the application being installed from an unknown source). In addition, the electronic device 101 may provide a list of applications that pose a security threat and related information to the user and may guide the user how to easily remove the applications);
determining, based on attribute information of the first application, whether the first application is a rogue application (par. 50 attribute lists is source type to denote a risk of untrusted application and list these applications); and
in a case that the first application is a rogue application, replacing an original icon corresponding to the first application with a preset icon, and displaying the preset icon at an application icon location of the first application on a desktop of the electronic device, wherein the preset icon is used to remind a user of the rogue application (par. 74 replacing the application icon with an identifying icon to denote untrusted application; fig. 4A-B).
As for claim 2, Jang teaches. The method according to claim 1, wherein the second list does not comprise a determined rogue application (fig. 3B item 350 when the workflow goes through the list of applications to check, the condition of 350 “untrusted application” is negative then proceed to no branch and skip 360 which is changing the application icon, thus in a given scenario that all applications checked are on the allow list then the second list would not have a rogue application by means of this workflow; par. 72-74).
As for claim 3, Jang teaches. The method according to claim 1, wherein the attribute information of the first application comprises an application name of the first application and an application icon of the first application, and the determining, based on attribute information of the first application, whether the first application is a rogue application comprises:
when the application name of the first application is empty and the application icon of the first application is transparent, determining that the first application is a rogue application the first application is a rogue application (par. 75 a malicious application can be hidden and not show any information (given example is icon but the name under the icon would be implied here as well); Some malicious applications may be provided without an icon such that the malicious applications are hidden after the malicious applications are installed. The symbol 430 may be displayed as an icon of a corresponding application as illustrated in FIG. 4B, such that the user may effectively recognize the presence of the application).
As for claim 4, Jang teaches. The method according to claim 1, wherein the attribute information of the first application comprises an action quantity and an action status of the first application, and the determining, based on attribute information of the first application, whether the first application is a rogue application comprises: in a case that the action quantity of the first application is greater than 0 and the action status is disabled, the first application is a rogue application, wherein the action quantity is used to represent a quantity of to-be-executed actions of the first application, and the action status is used to represent a status of the to-be-executed action of the first application (par. 80 untrusted application tries to access information, thereby an action quantity is greater than one or one attempt and the status of the untrusted application will not work because the security disables after this detection and the application status is now disabled; “disabling action status “permit the untrusted application to access information on user identity or important information or may prevent the information from being provided; wherein the action quantity is the untrusted application trying to access information from a text; “When the untrusted application has permission to access a text message, the processor 120 may prevent the untrusted application from accessing information, such as personal information or authentication numbers included in the text message, or transmit data from which corresponding information has been deleted to the untrusted application.”).
As for claim 5, Jang teaches. The method according to claim 3, wherein after the determining, based on attribute information of the first application, whether the first application is a rogue application, the method further comprises:
after preset duration, determining whether a white list comprises the first application, wherein the white list comprises a plurality of verified non-rogue applications; and
if the white list does not comprise the first application, the first application is a rogue application (par. 71 An untrusted application may be an application of which a source may not be trusted and that may itself not be trusted. In response to the application being included in an allowlist, a list of trusted applications, the processor 120 may determine the application to be a trusted application regardless of the source type of the application).
As for claim 6, Jang teaches. The method according to claim 1, wherein the first list comprises application information of a plurality of applications, the application information comprises an application package, an application name, an application icon, a first flag bit, a second flag bit, and a third flag bit (par. 27 flags are common identifiers in storage systems, par. 27 would encompass such techniques for identifying data and storing: According to an example embodiment, as at least a part of data processing or computation, the processor 120 may store a command or data received from another component (e.g., the sensor module 176 or the communication module 190) in a volatile memory 132, process the command or the data stored in the volatile memory 132, and store resulting data in a non-volatile memory 134; par. 61 According to an embodiment, the installer checker 212 may check an installer based on a package setting file (e.g., packages.xml) of the application managed by the package management module 220. The package setting file, as a file containing information on the application installation file, may provide meta information of the installation file);
the first flag bit is used to identify whether an application is a rogue application (par. 82 The processor 120 may obtain a list of all applications installed on the electronic device through a package management module (e.g., the package management module 220 of FIG. 2 ) and analyze a package setting file (e.g., packages.xml) to identify applications classified as an untrusted application among all applications), the second flag bit is used to identify whether an application is a system application (par. 63 When the installOriginator field does not exist in the package setting file of the application and an installation folder of the application is located in a folder (e.g., a /system/app folder or a subfolder of a /system/priv-app folder) in which a default application of a manufacturer or a telecommunication company is installed, the installer checker 212 may classify the application as a default application. A default application may be referred to as a ‘preload application), and the third flag bit is used to identify an installation source of an application (par. 50 According to example embodiments described hereinafter, the electronic device 101 may provide a solution according to a source type by classifying a source type of the application 146 when installing the application 146. The electronic device 101 may classify a source type based on a source of the application 146 at a time at which the application 146 may be being installed and may manage applications classified as an untrusted application).
As for claim 7, Jang teaches. The method according to claim 6, wherein after the case that the first application is a rogue application, the method further comprises: updating a first flag bit that is of the first application and that is in the first list (par. 82 The processor 120 may obtain a list of all applications installed on the electronic device through a package management module (e.g., the package management module 220 of FIG. 2 ) and analyze a package setting file (e.g., packages.xml) to identify applications classified as an untrusted application among all applications.).
As for claim 8, Jang teaches. The method according to claim 1, wherein the preset condition comprises that the electronic device is started and enters the desktop, an application on the electronic device returns to the desktop, an application is installed on the electronic device, and an application is uninstalled from the electronic device (par. 52 preset is determined based upon default applications of the system; processor 120 may classify the source type of the application 146 as one of a trusted application, an untrusted application, and a default application based on the source information of the application 146. In response to the application 146 being included in an allowlist, a list of trusted applications, the processor 120 may determine that the application 146 may be a trusted application regardless of the source type of the application 146. In response to the application 146 corresponding to a default application, the processor 120 may treat the application 146 as a trusted application regardless of the source type of the application 146. The processor 120 may provide application information including the source type of the application 146 to a user).
(Note :) It is noted that any citation to specific, pages, columns, lines, or figures in the prior art references and any interpretation of the references should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. In re Heck, 699 F.2d 1331, 1332-33, 216 USPQ 1038, 1039 (Fed. Cir. 1983) (quoting In re Lemelson, 397 F.2d 1006,1009, 158 USPQ 275, 277 (CCPA 1968)).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
USE OF DEVICE RISK EVALUATION TO MANAGE ACCESS TO SERVICES
Document ID
US 20180359244 A1
Date Published
2018-12-13
Abstract
A method includes: receiving a request regarding access by a first computing device (e.g., a mobile device of a user) to a service; in response to the request, performing, by a second computing device (e.g., a device risk evaluation server, or a server of an identity provider), an evaluation of the first computing device; and performing, by the second computing device, an action (e.g., authorizing access to the service) based on the evaluation.
SECURE EXECUTION OF ENTERPRISE APPLICATIONS ON MOBILE DEVICES
Document ID
US 20140007222 A1
Date Published
2014-01-02
Abstract
A system is disclosed that includes components and features for enabling enterprise users to securely access enterprise resources (documents, data, application servers, etc.) using their mobile devices. An enterprise can use some or all components of the system to, for example, securely but flexibly implement a BYOD (bring your own device) policy in which users can run both personal applications and secure enterprise applications on their mobile devices. The system may, for example, implement policies for controlling mobile device accesses to enterprise resources based on device attributes (e.g., what mobile applications are installed), user attributes (e.g., the user's position or department), behavioral attributes, and other criteria. Client-side code installed on the mobile devices may further enhance security by, for example, creating a secure container for locally storing enterprise data, creating a secure execution environment for running enterprise applications, and/or creating secure application tunnels for communicating with the enterprise system.
Inquires
Any inquiry concerning this communication should be directed to NICHOLAS AUGUSTINE at telephone number (571)270-1056.
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.
PNG
media_image1.png
213
559
media_image1.png
Greyscale
/NICHOLAS AUGUSTINE/Primary Examiner, Art Unit 2178 June 18, 2026
Prosecution Insights