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 .
Summary
This action is a responsive to the application filed on 7/24/2025.
Claims 1-20 are pending and have been examined.
Claims 1-20 are rejected.
Information Disclosure Statement
The information disclosure statements (IDS)s submitted on 8/5/2025, 4/2/2026, & 5/18/2026. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-6, -12, 19-20 provisionally rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-11 of copending Application No. 19008499. Although the claims at issue are not identical, they are not patentably distinct from each other.
This is a provisional nonstatutory double patenting rejection because the patentably indistinct claims have not in fact been patented.
Each of the instant application claims (claims 1, 19 and 20) is broader than the claims (1 and 11) in said U.S. Patent. For instance, claim 1 of the copending Application includes limitations not in claim 1 of the instant application. Since claim 19 and 20 in the instant application recites similar features as claim 1 of the instant application, same comparison can be made. Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to omit elements when the remaining elements perform as before. A person of ordinary skill could have arrived at the present claims by omitting the details of said U.S. Patent claims. See In re Karlson (CCPA) 136 USPQ 184, decided January 16, 1963 (“Omission of element and its function in combination is obvious expedient if remaining elements perform same function as before’).
An exemplary to show similarity among the conflicting claims (see table below).
Instant Application
copending Application No. 19008499
1. A system for managing user data privacy, the system comprising: a computer with one or more processor and memory, wherein the computer executes computer-readable instructions; and a network connection operatively connecting at least one user device to the computer; wherein, upon execution of the computer-readable instructions, the computer is configured to:
initiate providing, via a graphical user interface of the at least one user device, a user software application to a user for installation on the at least one user device, wherein the at least one user device is configured to wirelessly communicate with the computer via the user software application;
receive, via the user software application installed on the at least one user device, user data comprising personal information of the user;
display, via the graphical user interface, a dashboard of the user software application based on the user data, wherein a first screen of the dashboard displays a menu listing of one or more preferences and a preference summary associated with each of the preferences, and wherein the menu listing of the preferences includes a data sharing preference option and a marketing preference option;
and display, via the graphical user interface, a second screen of the dashboard based on a user selection of one of the preference options displayed on the first screen of the dashboard, wherein the second screen of the dashboard displays a plurality of verbal interaction preferences related to the user selection of one of the preference options, and wherein at least one of the verbal interaction preferences is an opt out preference.
1. A system for managing user data privacy, the system comprising:
a computer with one or more processor and memory, wherein the computer executes computer-readable instructions; and a network connection operatively connecting at least one user device to the computer; wherein, upon execution of the computer-readable instructions, the computer is configured to:
initiate providing, via a graphical user interface of the at least one user device, a user software application to a user for installation on the at least one user device, wherein the at least one user device is configured to wirelessly communicate with the computer via the user software application;
receive, via the user software application installed on the at least one user device, user data comprising personal information of the user;
display, via the graphical user interface, a dashboard of the user software application based on the user data, wherein a first screen of the dashboard displays a menu listing of one or more preferences and a preference summary associated with each of the preferences, and wherein the menu listing of the preferences includes a data sharing preference option and a marketing preference option;
display, via the graphical user interface, a second screen of the dashboard based on a user selection of one of the preference options displayed on the first screen of the dashboard, wherein the second screen of the dashboard displays a plurality of non-verbal interaction preferences related to the user selection of one of the preference options, and wherein at least one of the non-verbal interaction preferences is an opt out preference
2. The system of claim 1, wherein, upon execution of the computer-readable instructions, the computer is further configured to display, via the graphical user interface, a third screen of the dashboard in response to a setting of the verbal interaction preferences, wherein the third screen displays a confirmation that the verbal interaction preferences are submitted to the computer.
1. display, via the graphical user interface, a third screen of the dashboard in response to a setting of the non-verbal interaction preferences, wherein the third screen displays a confirmation that the non-verbal interaction preferences are submitted to the computer
3. The system of claim 1, wherein at least one of the verbal interaction preferences is dynamically updated based on a learning of a behavior of the user of the system.
2. The system of claim 1, wherein at least one of the non-verbal interaction preferences is dynamically updated based on a learning of a behavior of the user of the system.
4. The system of claim 1, wherein, upon execution of the computer-readable instructions, the computer is further configured to filter the user data based upon the verbal interaction preferences.
3. The system of claim 1, wherein, upon execution of the computer-readable instructions, the computer is further configured to filter the user data based upon the non-verbal interaction preferences.
5. The system of claim 1, wherein at least one of the verbal interaction preferences is received from at least one third-party system.
4. The system of claim 1, wherein at least one of the non-verbal interaction preferences is received from at least one third-party system.
6. The system of claim 1, wherein at least one of the verbal interaction preferences is received from a customer information file.
5. The system of claim 1, wherein at least one of the non-verbal interaction preferences is received from a customer information file.
9. The system of claim 1, wherein at least one of the verbal interaction preferences is an opt out of automatic decision making.
6. The system of claim 1, wherein at least one of the non-verbal interaction preferences is an opt out of automatic decision making.
10. The system of claim 1, wherein at least one of the verbal interaction preferences is an opt out of affiliate sharing.
7. The system of claim 1, wherein at least one of the non-verbal interaction preferences is an opt out of affiliate sharing.
11. The system of claim 1, wherein at least one of the verbal interaction preferences is an opt out of third party sharing.
8. The system of claim 1, wherein at least one of the non-verbal interaction preferences is an opt out of third party sharing.
12. The system of claim 1, wherein at least one of the verbal interaction preferences is an opt out of marketing verbal interactions for one or more telephone numbers of the user.
10. The system of claim 1, wherein at least one of the non-verbal interaction preferences is an opt out of marketing non-verbal interactions for one or more telephone numbers of the user.
19. A system for managing user data privacy, the system comprising: a computer with one or more processor and memory, wherein the computer executes computer-readable instructions; and a network connection operatively connecting at least one user device to the computer; wherein, upon execution of the computer-readable instructions, the computer is configured to:
initiate providing, via a graphical user interface of the at least one user device, a user software application to a user for installation on the at least one user device, wherein the at least one user device is configured to wirelessly communicate with the computer via the user software application;
receive, via the user software application installed on the at least one user device, user data comprising personal information of the user;
display, via the graphical user interface, a dashboard of the user software application based on the user data, wherein a first screen of the dashboard displays a menu listing of one or more preferences and a preference summary associated with each of the preferences, and wherein the menu listing of the preferences includes a data sharing preference option and a marketing preference option;
and display, via the graphical user interface, a second screen of the dashboard based on a user selection of the data sharing preference option displayed on the first screen of the dashboard, wherein the second screen of the dashboard displays a plurality of interaction preferences related to the user selection of the data sharing preference option, and wherein at least one of the interaction preferences is an opt out preference;
and display, via the graphical user interface, a third screen of the dashboard based on a user selection of the marketing preference option displayed on the first screen of the dashboard, wherein the third screen of the dashboard displays a plurality of verbal interaction preferences related to the user selection of the marketing preference option, and wherein at least one of the verbal interaction preferences is an opt out preference.
1. A system for managing user data privacy, the system comprising:
a computer with one or more processor and memory, wherein the computer executes computer-readable instructions; and a network connection operatively connecting at least one user device to the computer; wherein, upon execution of the computer-readable instructions, the computer is configured to:
initiate providing, via a graphical user interface of the at least one user device, a user software application to a user for installation on the at least one user device, wherein the at least one user device is configured to wirelessly communicate with the computer via the user software application;
receive, via the user software application installed on the at least one user device, user data comprising personal information of the user;
display, via the graphical user interface, a dashboard of the user software application based on the user data, wherein a first screen of the dashboard displays a menu listing of one or more preferences and a preference summary associated with each of the preferences, and wherein the menu listing of the preferences includes a data sharing preference option and a marketing preference option;
display, via the graphical user interface, a second screen of the dashboard based on a user selection of one of the preference options displayed on the first screen of the dashboard, wherein the second screen of the dashboard displays a plurality of non-verbal interaction preferences related to the user selection of one of the preference options, and wherein at least one of the non-verbal interaction preferences is an opt out preference
and display, via the graphical user interface, a third screen of the dashboard in response to a setting of the non-verbal interaction preferences, wherein the third screen displays a confirmation that the non-verbal interaction preferences are submitted to the computer
20. A method for managing user data privacy using a graphical user interface, comprising the steps of: providing a computer with one or more processor and memory, wherein the computer executes computer-readable instructions;
providing a network connection operatively connecting at least one user device to the computer; providing, via a graphical user interface of the at least one user device, a user software application to a user for installation on the at least one user device, wherein the at least one user device is configured to wirelessly communicate with the computer via the user software application;
receiving, via the user software application installed on the at least one user device, user data comprising personal information of the user;
displaying, via the graphical user interface, a dashboard of the user software application based on the user data, wherein a first screen of the dashboard displays a menu listing of one or more preferences and a preference summary associated with each of the preferences, and wherein the menu listing of the preferences includes a data sharing preference option and a marketing preference option;
and displaying, via the graphical user interface, a second screen of the dashboard based on a user selection of one of the preference options displayed on the first screen of the dashboard, wherein the second screen of the dashboard displays a plurality of verbal interaction preferences related to the user selection of one of the preference options, and wherein at least one of the verbal interaction preferences is an opt out preference.
11. A method for managing user data privacy using a graphical user interface, comprising the steps of: providing a computer with one or more processor and memory, wherein the computer executes computer-readable instructions;
providing a network connection operatively connecting at least one user device to the computer; providing, via a graphical user interface of the at least one user device, a user software application to a user for installation on the at least one user device, wherein the at least one user device is configured to wirelessly communicate with the computer via the user software application;
receiving, via the user software application installed on the at least one user device, user data comprising personal information of the user;
displaying, via the graphical user interface, a dashboard of the user software application based on the user data, wherein a first screen of the dashboard displays a menu listing of one or more preferences and a preference summary associated with each of the preferences, and wherein the menu listing of the preferences includes a data sharing preference option and a marketing preference option;
displaying, via the graphical user interface, a second screen of the dashboard based on a user selection of one of the preference options displayed on the first screen of the dashboard, wherein the second screen of the dashboard displays a plurality of non-verbal interaction preferences related to the user selection of one of the preference options, and wherein at least one of the non-verbal interaction preferences is an opt out preference;
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.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1-6, 8, 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Sadeh et al. (US 20190108353 A1) and further in view of Prevost et al. (US 20130191481 A1).
As to claim 1, Sadeh et al. teaches A system for managing user data privacy, the system comprising: a computer with one or more processor and memory, wherein the computer executes computer-readable instructions; and a network connection operatively connecting at least one user device to the computer; wherein, upon execution of the computer-readable instructions (See ¶ [0025], Teaches that FIG. 1A illustrates a deployment of a Personalized Privacy Assistant 230 to configure permission settings 231 on a user computing device 114 such as a smartphone or tablet, with the permission settings controlling access to both sensitive on-device functionality 140 (e.g. GPS, camera, microphone) and sensitive on-device data 141 (e.g. contacts list, health information, IMEI number), and sensitive off-device (or external) third party data 151 and functionality 150 (e.g., social media data and functionality (such as accessing the user's Facebook account and/or posting on the user's Facebook account), third party payment data and functionality, information from third party health and fitness devices, external calendar or email services for the user). FIG. 1B illustrates a deployment of a Personalized Privacy Assistant 230 to help users configure user-specific privacy settings associated with different external IoT resources such as IoT apps, IoT devices or IoT services, according to various embodiments of the present invention.),
the computer is configured to: initiate providing, via a graphical user interface of the at least one user device, a user software application to a user for installation on the at least one user device, wherein the at least one user device is configured to wirelessly communicate with the computer via the user software application (See ¶¶ [0025]-[0026], [0067], Teaches that FIGS. 1A and 1B are diagrams illustrating two different ways of deploying a personalized privacy assistant to help users configure privacy settings according to various embodiments of the present invention. FIG. 1A illustrates a deployment of a Personalized Privacy Assistant 230 to configure permission settings 231 on a user computing device 114 such as a smartphone or tablet, with the permission settings controlling access to both sensitive on-device functionality 140 (e.g. GPS, camera, microphone) and sensitive on-device data 141 (e.g. contacts list, health information, IMEI number), and sensitive off-device (or external) third party data 151 and functionality 150 (e.g., social media data and functionality (such as accessing the user's Facebook account and/or posting on the user's Facebook account), third party payment data and functionality, information from third party health and fitness devices, external calendar or email services for the user). FIG. 1B illustrates a deployment of a Personalized Privacy Assistant 230 to help users configure user-specific privacy settings associated with different external IoT resources such as IoT apps, IoT devices or IoT services, according to various embodiments of the present invention. As shown in FIGS. 1A and 1B, the Personalized Privacy Assistant (PPA) may be itself an application running on a computing device operated by the user (e.g. a desktop, a laptop, a tablet, a wearable computing device, a smart TV, a smart fridge, a smart car, a robot), or it may be running on a server (e.g. a server running in the cloud) and simply interact with the user via an application such as a browser. The PPA's functionality may also be distributed across any number of computing systems with some of its functionality running locally on a computing device in the user's possession and some of its functionality running on one or more servers);
display, via the graphical user interface, a dashboard of the user software application based on the user data, wherein a first screen of the dashboard displays a menu listing of one or more preferences and a preference summary associated with each of the preferences, and wherein the menu listing of the preferences includes a data sharing preference option and a marketing preference option (See ¶¶ [0054], [0046], Figs. 4-5, 8a-8c, Teaches that the recommendations display provided by the interface to the user may also provide the user with the option of requesting an explanation of the recommendation. One such embodiment is shown in FIG. 5. In the illustrated embodiment, several recommendations are made by the system. Each recommendation has an input means, such as a slide switch, that allows the user to allow or deny a given permission to an app. There is also, in the illustrated exemplary embodiment, a question mark (“?”) for each recommendation. FIG. 4 shows an embodiment of a privacy nudge 400 graphically rendered on, for example, the user's computing device 114 according to various embodiments of the present invention. In the illustrated example, the privacy nudge indicates the total number of instances that an app was granted access to data or functionality controlled by a permission, namely in the illustrated example, the user's location. Moreover, an app component 404 can display the number of instances that particular apps used a permitted privacy-related permission, such as accessing location data, as in the illustrated example. In addition, in this particular instance, a purpose component 406 of the privacy nudge 400 indicates the probable purpose for which the accessed location data is used, such as targeted advertising or consumer tracking and profiling. Such purpose information might further motivate a user to review his or her settings, as it might come as a surprise or might reveal to the user data practices that he or she might not feel comfortable with. In this particular instance, purpose associated with each permission request was derived from an analysis of the app's code, looking in particular at whether requests for particular permissions originate from third party libraries or not, and inferring the likely purpose(s) for accessing the permission accordingly (e.g., permission accessed to support the app's core functionality when first party code is responsible for the request, permission accessed to share information with a social networking site when the permission request originates from a third party library associated with a social networking site, with an analytics company when it originates from a third party library associated with an analytics company, with an advertising network when it originates from a library associated with an advertising network, etc.), as detailed in J. Lin et al., “Modeling users mobile app privacy preferences: Restoring usability in a sea of permission settings,” 2014 Symposium On Usable Privacy and Security (2015), which is incorporated herein by reference. In other embodiments such information can be inferred from descriptions of the apps, from information directly provided by the app's developer, from analysis of the app's behavior and the traffic it generates, or even from user reviews.);
and display, via the graphical user interface, a second screen of the dashboard based on a user selection of one of the preference options displayed on the first screen of the dashboard, wherein the second screen of the dashboard displays a plurality of verbal interaction preferences related to the user selection of one of the preference options, and wherein at least one of the verbal interaction preferences is an opt out preference (See ¶¶ [0053], [0073], [0024], Teaches that FIG. 8A-C show illustrative displays according to embodiments of the present invention of how the user could provide feedback. First, as shown in FIG. 8A, the user could be presented with a screen where permissions are organized by types of permissions (e.g., location, contacts, messages, etc.) with an identification of the number of apps that request each type of permission. The user could then select one type of permission, which then causes the display to list the apps that request that type of permission, along with any recommendation by the PPA to possibly deny some of these permissions, if they are not yet denied. The reader will appreciate that a number of ways of presenting recommended permission settings are possible. In this particular embodiment, the user can then go through the recommended setting changes (e.g., recommendation to change the location permission requested by the PayPal app from “grant” to “deny” in FIG. 8B, or to change the (access) contacts permission from “grant” to “deny” for the CitiMobile app in FIG. 8C). In this particular embodiment, the user can accept or ignore each recommended setting change. In doing so, the user provides feedback to the PPA. This feedback can in turn be used to refine the user's Individual Privacy Preference model (step 2310 in FIG. 12). In this particular embodiment, the user can review each permission for each individual app as shown in the examples of FIGS. 8B (app requesting location) and 8C (apps requesting contacts), decide whether to accept or ignore different recommended settings, modify settings for which the PPA does not provide any recommendations, or modify earlier setting changes, including changes that may have been prompted by the PPA's recommendations. The permission settings control access by these technologies (e.g. apps on a computing device, IoT service, IoT app, IoT device, etc.) to sensitive data or functionality. An example is a set of permissions that enable a mobile operating system to control access to sensitive functionality or data by apps running on a smartphone (e.g., access to location tracking functionality, access to camera functionality, access to microphone functionality, access to messaging functionality, access to contacts list information, access to a device's unique identifier, access to health information, etc.). In another example, permissions control privacy and/or security settings associated with a browser or control which sensitive functionality or data websites can access. In yet another example, permissions may be used to capture and enforce user-specific settings associated with Internet of Things (IoT) devices or services such as opt-in or opt-out privacy settings associated with location tracking functionality in an office building, or permission to apply facial recognition functionality or scene recognition functionality to footage captured by a video monitoring system in a mall.).
However, it does not expressly teach the details of receive, via the user software application installed on the at least one user device, user data comprising personal information of the user.
Prevost et al., from analogous art, teaches receive, via the user software application installed on the at least one user device, user data comprising personal information of the user (See ¶¶ [0134]-[0135, Teaches that user device peripheral data is received via an entity software application (606). In some implementations, the peripheral data (e.g., contextual data 510 as described in relation to FIG. 5) may be polled prior to service of an event to the user of the user device. For example, geolocation information may be polled prior to service of an event, such that one or more contextual events, contextual features, and/or workflow steps may be added to the event. In some implementations, the peripheral data may be collected upon service of information associated with an event to the user. The peripheral data, for example, may be included within a response from the user to information issued by the multi-channel communication environment on behalf of the entity. The peripheral data, in some implementations, may be provided by a multi-channel sub-application of an entity software application, such as the multi-channel sub-application 506 described in relation to FIG. 5. For example, upon an event (e.g., launching of the entity software application, using an eWallet account via the entity software application, etc.), the multi-channel sub-application may provide peripheral data to the multi-channel communication environment. In another example, while the multi-channel sub-application is active, the multi-channel sub-application may collect peripheral data and provide it (e.g., on a periodic and/or event-driven basis) to the multi-channel communication environment. The peripheral data, in some implementations, is stored by the multi-channel communication environment. For example, a portion of the peripheral data may be collected for managing event service and/or transaction history by the entity, and/or for establishing behavior patterns of the user. The peripheral data, for example, may be stored within the user profile data store 124, as described in relation to FIG. 5.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Prevost et al. into Sadeh et al. in order to determine a communication channel for delivering information associated with the event to the first user (See Prevost et al. ¶ [0005]).
As to claim 2, the combination of Sadeh et al. and Prevost et al. teaches the system according to claim 1 above. Sadeh et al. further teaches wherein, upon execution of the computer-readable instructions, the computer is further configured to display, via the graphical user interface, a third screen of the dashboard in response to a setting of the verbal interaction preferences, wherein the third screen displays a confirmation that the verbal interaction preferences are submitted to the computer (See ¶¶ [0053], [0073], [0024], Teaches that FIG. 8A-C show illustrative displays according to embodiments of the present invention of how the user could provide feedback. First, as shown in FIG. 8A, the user could be presented with a screen where permissions are organized by types of permissions (e.g., location, contacts, messages, etc.) with an identification of the number of apps that request each type of permission. The user could then select one type of permission, which then causes the display to list the apps that request that type of permission, along with any recommendation by the PPA to possibly deny some of these permissions, if they are not yet denied. The reader will appreciate that a number of ways of presenting recommended permission settings are possible. In this particular embodiment, the user can then go through the recommended setting changes (e.g., recommendation to change the location permission requested by the PayPal app from “grant” to “deny” in FIG. 8B, or to change the (access) contacts permission from “grant” to “deny” for the CitiMobile app in FIG. 8C). In this particular embodiment, the user can accept or ignore each recommended setting change. In doing so, the user provides feedback to the PPA. This feedback can in turn be used to refine the user's Individual Privacy Preference model (step 2310 in FIG. 12). In this particular embodiment, the user can review each permission for each individual app as shown in the examples of FIGS. 8B (app requesting location) and 8C (apps requesting contacts), decide whether to accept or ignore different recommended settings, modify settings for which the PPA does not provide any recommendations, or modify earlier setting changes, including changes that may have been prompted by the PPA's recommendations. The permission settings control access by these technologies (e.g. apps on a computing device, IoT service, IoT app, IoT device, etc.) to sensitive data or functionality. An example is a set of permissions that enable a mobile operating system to control access to sensitive functionality or data by apps running on a smartphone (e.g., access to location tracking functionality, access to camera functionality, access to microphone functionality, access to messaging functionality, access to contacts list information, access to a device's unique identifier, access to health information, etc.). In another example, permissions control privacy and/or security settings associated with a browser or control which sensitive functionality or data websites can access. In yet another example, permissions may be used to capture and enforce user-specific settings associated with Internet of Things (IoT) devices or services such as opt-in or opt-out privacy settings associated with location tracking functionality in an office building, or permission to apply facial recognition functionality or scene recognition functionality to footage captured by a video monitoring system in a mall.).
As to claim 3, the combination of Sadeh et al. and Prevost et al. teaches the system according to claim 1 above. However, it does not expressly teach the details of wherein at least one of the verbal interaction preferences is dynamically updated based on a learning of a behavior of the user of the system.
Prevost et al., from analogous art, teaches wherein at least one of the verbal interaction preferences is dynamically updated based on a learning of a behavior of the user of the system (See ¶ [0135], Teaches that The peripheral data, in some implementations, is stored by the multi-channel communication environment. For example, a portion of the peripheral data may be collected for managing event service and/or transaction history by the entity, and/or for establishing behavior patterns of the user. The peripheral data, for example, may be stored within the user profile data store 124, as described in relation to FIG. 5.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Prevost et al. into the combination of Sadeh et al. and Prevost et al. in order to determine a communication channel for delivering information associated with the event to the first user (See Prevost et al. ¶ [0005]).
As to claim 4, the combination of Sadeh et al. and Prevost et al. teaches the system according to claim 1 above. However, it does not expressly teach the details of wherein, upon execution of the computer-readable instructions, the computer is further configured to filter the user data based upon the verbal interaction preferences.
Prevost et al., from analogous art, teaches wherein, upon execution of the computer-readable instructions, the computer is further configured to filter the user data based upon the verbal interaction preferences (See ¶¶ [0037]-[0040], Teaches that A user, in some implementations, connects to a channel agent 112 of the multi-channel communication environment 102 to configure a number of communication channels 116 for distribution of information provided by at least one of the one or more communication sources 106. The communication channels 116, in some examples, can include an email channel 116 a, a voicemail channel 116 b, a text message channel 116 c, a mobile application channel 116 d, and a social networking channel 116 e. In further examples, the communication channels 116 can include a machine-to-machine (e.g., device alias) channel such as a smart car channel 116 f, and a smart TV channel 116 g. In some implementations, a user may configure one or more of a particular type of communication channel 116. For example, the user may configure two or more email addresses 116 a for distribution of information. Conversely, a particular communication source 106, such as a financial server 106 a, a Web portal 106 b, or a message server 106 c, may provide a user the opportunity to configure one or more communication channels 116 for distribution of information from the particular communication source. For example, a user may establish an account with the multi-channel communication environment 102 via an interface provided by a bank associated with the financial server 106 a. The interface, for example, may be included in a web page or mobile application provided by the bank to the user. Through the interface, the user may opt to receive, for example, fraud warnings via the SMS channel 116 c, monthly statements via the email channel 116 a, and offers for new products via the mobile application channel 116 d. In some implementations, the channel agent 112 provides the user with configuration tools to configure a particular channel 116 (e.g., email address, telephone number, social networking account, etc.) with a particular type of communication. The type of communication, for example, may include a priority of information or a source of information. For example, communications regarding a credit card may be directed to the SMS channel 116 c, while communications regarding new offers from the user's bank may be directed to a personal email account (e.g., email channel 116 a). Specific user settings are stored, for example, within a user profile data store 124. In some implementations, the configuration tools include tools for populating and managing information items related to a user profile such as, in some examples, user demographic information (e.g., name, address, birth date, marital status, number of children, pets, etc.), work experience information (e.g., company name, work address, education level, degree, graduation year, post-secondary school name(s), field of employment, etc.), and account information (e.g., awards member identifier, credit card number, bank account number, library card number, student identification, employee identification, eWallet account identification, medical insurance identification, dental insurance identification, etc.). The information items can include one or more of text information, image files, video files, and/or audio files.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Prevost et al. into the combination of Sadeh et al. and Prevost et al. in order to determine a communication channel for delivering information associated with the event to the first user (See Prevost et al. ¶ [0005]).
As to claim 5, the combination of Sadeh et al. and Prevost et al. teaches the system according to claim 1 above. Sadeh et al. further teaches wherein at least one of the verbal interaction preferences is received from at least one third-party system (See ¶¶ [0046], Teaches that FIG. 4 shows an embodiment of a privacy nudge 400 graphically rendered on, for example, the user's computing device 114 according to various embodiments of the present invention. In the illustrated example, the privacy nudge indicates the total number of instances that an app was granted access to data or functionality controlled by a permission, namely in the illustrated example, the user's location. Moreover, an app component 404 can display the number of instances that particular apps used a permitted privacy-related permission, such as accessing location data, as in the illustrated example. In addition, in this particular instance, a purpose component 406 of the privacy nudge 400 indicates the probable purpose for which the accessed location data is used, such as targeted advertising or consumer tracking and profiling. Such purpose information might further motivate a user to review his or her settings, as it might come as a surprise or might reveal to the user data practices that he or she might not feel comfortable with. In this particular instance, purpose associated with each permission request was derived from an analysis of the app's code, looking in particular at whether requests for particular permissions originate from third party libraries or not, and inferring the likely purpose(s) for accessing the permission accordingly (e.g., permission accessed to support the app's core functionality when first party code is responsible for the request, permission accessed to share information with a social networking site when the permission request originates from a third party library associated with a social networking site, with an analytics company when it originates from a third party library associated with an analytics company, with an advertising network when it originates from a library associated with an advertising network, etc.), as detailed in J. Lin et al., “Modeling users mobile app privacy preferences: Restoring usability in a sea of permission settings,” 2014 Symposium On Usable Privacy and Security (2015), which is incorporated herein by reference. In other embodiments such information can be inferred from descriptions of the apps, from information directly provided by the app's developer, from analysis of the app's behavior and the traffic it generates, or even from user reviews.).
As to claim 6, the combination of Sadeh et al. and Prevost et al. teaches the system according to claim 1 above. Sadeh et al. further teaches wherein at least one of the verbal interaction preferences is received from a customer information file (See ¶¶ [0048], Teaches that collective privacy preference models can come in the form of a number of privacy preference profiles obtained by clustering users with similar privacy preferences and identifying profiles of permission settings that users in a given cluster strongly agree on. The PPA can use these profiles to identify for each user the cluster (and profile) that best matches his/her privacy preferences. The privacy preference profiles can comprise, in one embodiment, collections of permission settings that test subjects in a given cluster strongly agree on (e.g. a threshold percentage of test subjects in the cluster concur on granting a given permission to a given category of apps for a given purpose, or concur on denying a given permission to a given category of apps, or more generally settings identified for different clusters of users using machine learning and statistical techniques such as Support Vector Machines, Random Forests, or other available machine learning and statistical techniques). A clustering technique for deriving the profiles is described in more detail herein. Different possible features can be used to identify clusters of users and associated privacy profiles, as well as build other types of privacy preference models. This includes building finer models that distinguish between individual apps (especially in the case of particularly popular apps, for which ample data from test subjects is likely to be available), building models that distinguish between finer types of purposes, building models that distinguish between different categories of third parties with which data might be shared or even individual third parties, building models that take into account additional information such as the retention policy associated with the collection of data, whether the data is aggregated or anonymized and more.).
As to claim 8, the combination of Sadeh et al. and Prevost et al. teaches the system according to claim 1 above. Sadeh et al. further teaches wherein at least one of the verbal interaction preferences is received from an application of the system separate from the user software application (See ¶¶ [0046], Teaches that FIG. 4 shows an embodiment of a privacy nudge 400 graphically rendered on, for example, the user's computing device 114 according to various embodiments of the present invention. In the illustrated example, the privacy nudge indicates the total number of instances that an app was granted access to data or functionality controlled by a permission, namely in the illustrated example, the user's location. Moreover, an app component 404 can display the number of instances that particular apps used a permitted privacy-related permission, such as accessing location data, as in the illustrated example. In addition, in this particular instance, a purpose component 406 of the privacy nudge 400 indicates the probable purpose for which the accessed location data is used, such as targeted advertising or consumer tracking and profiling. Such purpose information might further motivate a user to review his or her settings, as it might come as a surprise or might reveal to the user data practices that he or she might not feel comfortable with. In this particular instance, purpose associated with each permission request was derived from an analysis of the app's code, looking in particular at whether requests for particular permissions originate from third party libraries or not, and inferring the likely purpose(s) for accessing the permission accordingly (e.g., permission accessed to support the app's core functionality when first party code is responsible for the request, permission accessed to share information with a social networking site when the permission request originates from a third party library associated with a social networking site, with an analytics company when it originates from a third party library associated with an analytics company, with an advertising network when it originates from a library associated with an advertising network, etc.), as detailed in J. Lin et al., “Modeling users mobile app privacy preferences: Restoring usability in a sea of permission settings,” 2014 Symposium On Usable Privacy and Security (2015), which is incorporated herein by reference. In other embodiments such information can be inferred from descriptions of the apps, from information directly provided by the app's developer, from analysis of the app's behavior and the traffic it generates, or even from user reviews.).
As to claim 15, the combination of Sadeh et al. and Prevost et al. teaches the system according to claim 1 above. Sadeh et al. further teaches wherein at least one of the verbal interaction preferences is transmitted by the computer to a privacy preferences and consent management module (See ¶¶ [0048], Teaches that collective privacy preference models can come in the form of a number of privacy preference profiles obtained by clustering users with similar privacy preferences and identifying profiles of permission settings that users in a given cluster strongly agree on. The PPA can use these profiles to identify for each user the cluster (and profile) that best matches his/her privacy preferences. The privacy preference profiles can comprise, in one embodiment, collections of permission settings that test subjects in a given cluster strongly agree on (e.g. a threshold percentage of test subjects in the cluster concur on granting a given permission to a given category of apps for a given purpose, or concur on denying a given permission to a given category of apps, or more generally settings identified for different clusters of users using machine learning and statistical techniques such as Support Vector Machines, Random Forests, or other available machine learning and statistical techniques). A clustering technique for deriving the profiles is described in more detail herein. Different possible features can be used to identify clusters of users and associated privacy profiles, as well as build other types of privacy preference models. This includes building finer models that distinguish between individual apps (especially in the case of particularly popular apps, for which ample data from test subjects is likely to be available), building models that distinguish between finer types of purposes, building models that distinguish between different categories of third parties with which data might be shared or even individual third parties, building models that take into account additional information such as the retention policy associated with the collection of data, whether the data is aggregated or anonymized and more.).
As to claim 16, the combination of Sadeh et al. and Prevost et al. teaches the system according to claim 1 above. Sadeh et al. further teaches wherein at least one of the verbal interaction preferences is transmitted by the computer to a customer information file (See ¶¶ [0048], Teaches that collective privacy preference models can come in the form of a number of privacy preference profiles obtained by clustering users with similar privacy preferences and identifying profiles of permission settings that users in a given cluster strongly agree on. The PPA can use these profiles to identify for each user the cluster (and profile) that best matches his/her privacy preferences. The privacy preference profiles can comprise, in one embodiment, collections of permission settings that test subjects in a given cluster strongly agree on (e.g. a threshold percentage of test subjects in the cluster concur on granting a given permission to a given category of apps for a given purpose, or concur on denying a given permission to a given category of apps, or more generally settings identified for different clusters of users using machine learning and statistical techniques such as Support Vector Machines, Random Forests, or other available machine learning and statistical techniques). A clustering technique for deriving the profiles is described in more detail herein. Different possible features can be used to identify clusters of users and associated privacy profiles, as well as build other types of privacy preference models. This includes building finer models that distinguish between individual apps (especially in the case of particularly popular apps, for which ample data from test subjects is likely to be available), building models that distinguish between finer types of purposes, building models that distinguish between different categories of third parties with which data might be shared or even individual third parties, building models that take into account additional information such as the retention policy associated with the collection of data, whether the data is aggregated or anonymized and more.).
As to claim 17, the combination of Sadeh et al. and Prevost et al. teaches the system according to claim 1 above. Sadeh et al. further teaches wherein at least one of the verbal interaction preferences is transmitted to an application of the system separate from the user software application (See ¶¶ [0048], Teaches that collective privacy preference models can come in the form of a number of privacy preference profiles obtained by clustering users with similar privacy preferences and identifying profiles of permission settings that users in a given cluster strongly agree on. The PPA can use these profiles to identify for each user the cluster (and profile) that best matches his/her privacy preferences. The privacy preference profiles can comprise, in one embodiment, collections of permission settings that test subjects in a given cluster strongly agree on (e.g. a threshold percentage of test subjects in the cluster concur on granting a given permission to a given category of apps for a given purpose, or concur on denying a given permission to a given category of apps, or more generally settings identified for different clusters of users using machine learning and statistical techniques such as Support Vector Machines, Random Forests, or other available machine learning and statistical techniques). A clustering technique for deriving the profiles is described in more detail herein. Different possible features can be used to identify clusters of users and associated privacy profiles, as well as build other types of privacy preference models. This includes building finer models that distinguish between individual apps (especially in the case of particularly popular apps, for which ample data from test subjects is likely to be available), building models that distinguish between finer types of purposes, building models that distinguish between different categories of third parties with which data might be shared or even individual third parties, building models that take into account additional information such as the retention policy associated with the collection of data, whether the data is aggregated or anonymized and more.).
As to claim 18, the combination of Sadeh et al. and Prevost et al. teaches the system according to claim 1 above. Sadeh et al. further teaches wherein at least a portion of the verbal interaction preferences is transmitted by the computer as a batch file (See ¶¶ [0048], Teaches that collective privacy preference models can come in the form of a number of privacy preference profiles obtained by clustering users with similar privacy preferences and identifying profiles of permission settings that users in a given cluster strongly agree on. The PPA can use these profiles to identify for each user the cluster (and profile) that best matches his/her privacy preferences. The privacy preference profiles can comprise, in one embodiment, collections of permission settings that test subjects in a given cluster strongly agree on (e.g. a threshold percentage of test subjects in the cluster concur on granting a given permission to a given category of apps for a given purpose, or concur on denying a given permission to a given category of apps, or more generally settings identified for different clusters of users using machine learning and statistical techniques such as Support Vector Machines, Random Forests, or other available machine learning and statistical techniques). A clustering technique for deriving the profiles is described in more detail herein. Different possible features can be used to identify clusters of users and associated privacy profiles, as well as build other types of privacy preference models. This includes building finer models that distinguish between individual apps (especially in the case of particularly popular apps, for which ample data from test subjects is likely to be available), building models that distinguish between finer types of purposes, building models that distinguish between different categories of third parties with which data might be shared or even individual third parties, building models that take into account additional information such as the retention policy associated with the collection of data, whether the data is aggregated or anonymized and more.).
As to claim 19, Sadeh et al. teaches A system for managing user data privacy, the system comprising: a computer with one or more processor and memory, wherein the computer executes computer-readable instructions; and a network connection operatively connecting at least one user device to the computer; wherein, upon execution of the computer-readable instructions (See ¶ [0025], Teaches that FIG. 1A illustrates a deployment of a Personalized Privacy Assistant 230 to configure permission settings 231 on a user computing device 114 such as a smartphone or tablet, with the permission settings controlling access to both sensitive on-device functionality 140 (e.g. GPS, camera, microphone) and sensitive on-device data 141 (e.g. contacts list, health information, IMEI number), and sensitive off-device (or external) third party data 151 and functionality 150 (e.g., social media data and functionality (such as accessing the user's Facebook account and/or posting on the user's Facebook account), third party payment data and functionality, information from third party health and fitness devices, external calendar or email services for the user). FIG. 1B illustrates a deployment of a Personalized Privacy Assistant 230 to help users configure user-specific privacy settings associated with different external IoT resources such as IoT apps, IoT devices or IoT services, according to various embodiments of the present invention.),
the computer is configured to: initiate providing, via a graphical user interface of the at least one user device, a user software application to a user for installation on the at least one user device, wherein the at least one user device is configured to wirelessly communicate with the computer via the user software application (See ¶¶ [0025]-[0026], [0067], Teaches that FIGS. 1A and 1B are diagrams illustrating two different ways of deploying a personalized privacy assistant to help users configure privacy settings according to various embodiments of the present invention. FIG. 1A illustrates a deployment of a Personalized Privacy Assistant 230 to configure permission settings 231 on a user computing device 114 such as a smartphone or tablet, with the permission settings controlling access to both sensitive on-device functionality 140 (e.g. GPS, camera, microphone) and sensitive on-device data 141 (e.g. contacts list, health information, IMEI number), and sensitive off-device (or external) third party data 151 and functionality 150 (e.g., social media data and functionality (such as accessing the user's Facebook account and/or posting on the user's Facebook account), third party payment data and functionality, information from third party health and fitness devices, external calendar or email services for the user). FIG. 1B illustrates a deployment of a Personalized Privacy Assistant 230 to help users configure user-specific privacy settings associated with different external IoT resources such as IoT apps, IoT devices or IoT services, according to various embodiments of the present invention. As shown in FIGS. 1A and 1B, the Personalized Privacy Assistant (PPA) may be itself an application running on a computing device operated by the user (e.g. a desktop, a laptop, a tablet, a wearable computing device, a smart TV, a smart fridge, a smart car, a robot), or it may be running on a server (e.g. a server running in the cloud) and simply interact with the user via an application such as a browser. The PPA's functionality may also be distributed across any number of computing systems with some of its functionality running locally on a computing device in the user's possession and some of its functionality running on one or more servers);
display, via the graphical user interface, a dashboard of the user software application based on the user data, wherein a first screen of the dashboard displays a menu listing of one or more preferences and a preference summary associated with each of the preferences, and wherein the menu listing of the preferences includes a data sharing preference option and a marketing preference option (See ¶¶ [0054], [0046], Figs. 4-5, 8a-8c, Teaches that the recommendations display provided by the interface to the user may also provide the user with the option of requesting an explanation of the recommendation. One such embodiment is shown in FIG. 5. In the illustrated embodiment, several recommendations are made by the system. Each recommendation has an input means, such as a slide switch, that allows the user to allow or deny a given permission to an app. There is also, in the illustrated exemplary embodiment, a question mark (“?”) for each recommendation. FIG. 4 shows an embodiment of a privacy nudge 400 graphically rendered on, for example, the user's computing device 114 according to various embodiments of the present invention. In the illustrated example, the privacy nudge indicates the total number of instances that an app was granted access to data or functionality controlled by a permission, namely in the illustrated example, the user's location. Moreover, an app component 404 can display the number of instances that particular apps used a permitted privacy-related permission, such as accessing location data, as in the illustrated example. In addition, in this particular instance, a purpose component 406 of the privacy nudge 400 indicates the probable purpose for which the accessed location data is used, such as targeted advertising or consumer tracking and profiling. Such purpose information might further motivate a user to review his or her settings, as it might come as a surprise or might reveal to the user data practices that he or she might not feel comfortable with. In this particular instance, purpose associated with each permission request was derived from an analysis of the app's code, looking in particular at whether requests for particular permissions originate from third party libraries or not, and inferring the likely purpose(s) for accessing the permission accordingly (e.g., permission accessed to support the app's core functionality when first party code is responsible for the request, permission accessed to share information with a social networking site when the permission request originates from a third party library associated with a social networking site, with an analytics company when it originates from a third party library associated with an analytics company, with an advertising network when it originates from a library associated with an advertising network, etc.), as detailed in J. Lin et al., “Modeling users mobile app privacy preferences: Restoring usability in a sea of permission settings,” 2014 Symposium On Usable Privacy and Security (2015), which is incorporated herein by reference. In other embodiments such information can be inferred from descriptions of the apps, from information directly provided by the app's developer, from analysis of the app's behavior and the traffic it generates, or even from user reviews.);
and display, via the graphical user interface, a second screen of the dashboard based on a user selection of the data sharing preference option displayed on the first screen of the dashboard, wherein the second screen of the dashboard displays a plurality of interaction preferences related to the user selection of the data sharing preference option, and wherein at least one of the interaction preferences is an opt out preference (See ¶¶ [0053], [0073], [0024], Teaches that FIG. 8A-C show illustrative displays according to embodiments of the present invention of how the user could provide feedback. First, as shown in FIG. 8A, the user could be presented with a screen where permissions are organized by types of permissions (e.g., location, contacts, messages, etc.) with an identification of the number of apps that request each type of permission. The user could then select one type of permission, which then causes the display to list the apps that request that type of permission, along with any recommendation by the PPA to possibly deny some of these permissions, if they are not yet denied. The reader will appreciate that a number of ways of presenting recommended permission settings are possible. In this particular embodiment, the user can then go through the recommended setting changes (e.g., recommendation to change the location permission requested by the PayPal app from “grant” to “deny” in FIG. 8B, or to change the (access) contacts permission from “grant” to “deny” for the CitiMobile app in FIG. 8C). In this particular embodiment, the user can accept or ignore each recommended setting change. In doing so, the user provides feedback to the PPA. This feedback can in turn be used to refine the user's Individual Privacy Preference model (step 2310 in FIG. 12). In this particular embodiment, the user can review each permission for each individual app as shown in the examples of FIGS. 8B (app requesting location) and 8C (apps requesting contacts), decide whether to accept or ignore different recommended settings, modify settings for which the PPA does not provide any recommendations, or modify earlier setting changes, including changes that may have been prompted by the PPA's recommendations. The permission settings control access by these technologies (e.g. apps on a computing device, IoT service, IoT app, IoT device, etc.) to sensitive data or functionality. An example is a set of permissions that enable a mobile operating system to control access to sensitive functionality or data by apps running on a smartphone (e.g., access to location tracking functionality, access to camera functionality, access to microphone functionality, access to messaging functionality, access to contacts list information, access to a device's unique identifier, access to health information, etc.). In another example, permissions control privacy and/or security settings associated with a browser or control which sensitive functionality or data websites can access. In yet another example, permissions may be used to capture and enforce user-specific settings associated with Internet of Things (IoT) devices or services such as opt-in or opt-out privacy settings associated with location tracking functionality in an office building, or permission to apply facial recognition functionality or scene recognition functionality to footage captured by a video monitoring system in a mall.);
and display, via the graphical user interface, a third screen of the dashboard based on a user selection of the marketing preference option displayed on the first screen of the dashboard, wherein the third screen of the dashboard displays a plurality of verbal interaction preferences related to the user selection of the marketing preference option, and wherein at least one of the verbal interaction preferences is an opt out preference (See ¶¶ [0053], [0073], [0024], Teaches that FIG. 8A-C show illustrative displays according to embodiments of the present invention of how the user could provide feedback. First, as shown in FIG. 8A, the user could be presented with a screen where permissions are organized by types of permissions (e.g., location, contacts, messages, etc.) with an identification of the number of apps that request each type of permission. The user could then select one type of permission, which then causes the display to list the apps that request that type of permission, along with any recommendation by the PPA to possibly deny some of these permissions, if they are not yet denied. The reader will appreciate that a number of ways of presenting recommended permission settings are possible. In this particular embodiment, the user can then go through the recommended setting changes (e.g., recommendation to change the location permission requested by the PayPal app from “grant” to “deny” in FIG. 8B, or to change the (access) contacts permission from “grant” to “deny” for the CitiMobile app in FIG. 8C). In this particular embodiment, the user can accept or ignore each recommended setting change. In doing so, the user provides feedback to the PPA. This feedback can in turn be used to refine the user's Individual Privacy Preference model (step 2310 in FIG. 12). In this particular embodiment, the user can review each permission for each individual app as shown in the examples of FIGS. 8B (app requesting location) and 8C (apps requesting contacts), decide whether to accept or ignore different recommended settings, modify settings for which the PPA does not provide any recommendations, or modify earlier setting changes, including changes that may have been prompted by the PPA's recommendations. The permission settings control access by these technologies (e.g. apps on a computing device, IoT service, IoT app, IoT device, etc.) to sensitive data or functionality. An example is a set of permissions that enable a mobile operating system to control access to sensitive functionality or data by apps running on a smartphone (e.g., access to location tracking functionality, access to camera functionality, access to microphone functionality, access to messaging functionality, access to contacts list information, access to a device's unique identifier, access to health information, etc.). In another example, permissions control privacy and/or security settings associated with a browser or control which sensitive functionality or data websites can access. In yet another example, permissions may be used to capture and enforce user-specific settings associated with Internet of Things (IoT) devices or services such as opt-in or opt-out privacy settings associated with location tracking functionality in an office building, or permission to apply facial recognition functionality or scene recognition functionality to footage captured by a video monitoring system in a mall.).
However, it does not expressly teach the details of receive, via the user software application installed on the at least one user device, user data comprising personal information of the user.
Prevost et al., from analogous art, teaches receive, via the user software application installed on the at least one user device, user data comprising personal information of the user (See ¶¶ [0134]-[0135, Teaches that user device peripheral data is received via an entity software application (606). In some implementations, the peripheral data (e.g., contextual data 510 as described in relation to FIG. 5) may be polled prior to service of an event to the user of the user device. For example, geolocation information may be polled prior to service of an event, such that one or more contextual events, contextual features, and/or workflow steps may be added to the event. In some implementations, the peripheral data may be collected upon service of information associated with an event to the user. The peripheral data, for example, may be included within a response from the user to information issued by the multi-channel communication environment on behalf of the entity. The peripheral data, in some implementations, may be provided by a multi-channel sub-application of an entity software application, such as the multi-channel sub-application 506 described in relation to FIG. 5. For example, upon an event (e.g., launching of the entity software application, using an eWallet account via the entity software application, etc.), the multi-channel sub-application may provide peripheral data to the multi-channel communication environment. In another example, while the multi-channel sub-application is active, the multi-channel sub-application may collect peripheral data and provide it (e.g., on a periodic and/or event-driven basis) to the multi-channel communication environment. The peripheral data, in some implementations, is stored by the multi-channel communication environment. For example, a portion of the peripheral data may be collected for managing event service and/or transaction history by the entity, and/or for establishing behavior patterns of the user. The peripheral data, for example, may be stored within the user profile data store 124, as described in relation to FIG. 5.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Prevost et al. into Sadeh et al. in order to determine a communication channel for delivering information associated with the event to the first user (See Prevost et al. ¶ [0005]).
As to claim 20, Sadeh et al. teaches A method for managing user data privacy using a graphical user interface, comprising the steps of: providing a computer with one or more processor and memory, wherein the computer executes computer-readable instructions; providing a network connection operatively connecting at least one user device to the computer (See ¶ [0025], Teaches that FIG. 1A illustrates a deployment of a Personalized Privacy Assistant 230 to configure permission settings 231 on a user computing device 114 such as a smartphone or tablet, with the permission settings controlling access to both sensitive on-device functionality 140 (e.g. GPS, camera, microphone) and sensitive on-device data 141 (e.g. contacts list, health information, IMEI number), and sensitive off-device (or external) third party data 151 and functionality 150 (e.g., social media data and functionality (such as accessing the user's Facebook account and/or posting on the user's Facebook account), third party payment data and functionality, information from third party health and fitness devices, external calendar or email services for the user). FIG. 1B illustrates a deployment of a Personalized Privacy Assistant 230 to help users configure user-specific privacy settings associated with different external IoT resources such as IoT apps, IoT devices or IoT services, according to various embodiments of the present invention.),
providing, via a graphical user interface of the at least one user device, a user software application to a user for installation on the at least one user device, wherein the at least one user device is configured to wirelessly communicate with the computer via the user software application (See ¶¶ [0025]-[0026], [0067], Teaches that FIGS. 1A and 1B are diagrams illustrating two different ways of deploying a personalized privacy assistant to help users configure privacy settings according to various embodiments of the present invention. FIG. 1A illustrates a deployment of a Personalized Privacy Assistant 230 to configure permission settings 231 on a user computing device 114 such as a smartphone or tablet, with the permission settings controlling access to both sensitive on-device functionality 140 (e.g. GPS, camera, microphone) and sensitive on-device data 141 (e.g. contacts list, health information, IMEI number), and sensitive off-device (or external) third party data 151 and functionality 150 (e.g., social media data and functionality (such as accessing the user's Facebook account and/or posting on the user's Facebook account), third party payment data and functionality, information from third party health and fitness devices, external calendar or email services for the user). FIG. 1B illustrates a deployment of a Personalized Privacy Assistant 230 to help users configure user-specific privacy settings associated with different external IoT resources such as IoT apps, IoT devices or IoT services, according to various embodiments of the present invention. As shown in FIGS. 1A and 1B, the Personalized Privacy Assistant (PPA) may be itself an application running on a computing device operated by the user (e.g. a desktop, a laptop, a tablet, a wearable computing device, a smart TV, a smart fridge, a smart car, a robot), or it may be running on a server (e.g. a server running in the cloud) and simply interact with the user via an application such as a browser. The PPA's functionality may also be distributed across any number of computing systems with some of its functionality running locally on a computing device in the user's possession and some of its functionality running on one or more servers);
displaying, via the graphical user interface, a dashboard of the user software application based on the user data, wherein a first screen of the dashboard displays a menu listing of one or more preferences and a preference summary associated with each of the preferences, and wherein the menu listing of the preferences includes a data sharing preference option and a marketing preference option (See ¶¶ [0054], [0046], Figs. 4-5, 8a-8c, Teaches that the recommendations display provided by the interface to the user may also provide the user with the option of requesting an explanation of the recommendation. One such embodiment is shown in FIG. 5. In the illustrated embodiment, several recommendations are made by the system. Each recommendation has an input means, such as a slide switch, that allows the user to allow or deny a given permission to an app. There is also, in the illustrated exemplary embodiment, a question mark (“?”) for each recommendation. FIG. 4 shows an embodiment of a privacy nudge 400 graphically rendered on, for example, the user's computing device 114 according to various embodiments of the present invention. In the illustrated example, the privacy nudge indicates the total number of instances that an app was granted access to data or functionality controlled by a permission, namely in the illustrated example, the user's location. Moreover, an app component 404 can display the number of instances that particular apps used a permitted privacy-related permission, such as accessing location data, as in the illustrated example. In addition, in this particular instance, a purpose component 406 of the privacy nudge 400 indicates the probable purpose for which the accessed location data is used, such as targeted advertising or consumer tracking and profiling. Such purpose information might further motivate a user to review his or her settings, as it might come as a surprise or might reveal to the user data practices that he or she might not feel comfortable with. In this particular instance, purpose associated with each permission request was derived from an analysis of the app's code, looking in particular at whether requests for particular permissions originate from third party libraries or not, and inferring the likely purpose(s) for accessing the permission accordingly (e.g., permission accessed to support the app's core functionality when first party code is responsible for the request, permission accessed to share information with a social networking site when the permission request originates from a third party library associated with a social networking site, with an analytics company when it originates from a third party library associated with an analytics company, with an advertising network when it originates from a library associated with an advertising network, etc.), as detailed in J. Lin et al., “Modeling users mobile app privacy preferences: Restoring usability in a sea of permission settings,” 2014 Symposium On Usable Privacy and Security (2015), which is incorporated herein by reference. In other embodiments such information can be inferred from descriptions of the apps, from information directly provided by the app's developer, from analysis of the app's behavior and the traffic it generates, or even from user reviews.);
and displaying, via the graphical user interface, a second screen of the dashboard based on a user selection of one of the preference options displayed on the first screen of the dashboard, wherein the second screen of the dashboard displays a plurality of verbal interaction preferences related to the user selection of one of the preference options, and wherein at least one of the verbal interaction preferences is an opt out preference (See ¶¶ [0053], [0073], [0024], Teaches that FIG. 8A-C show illustrative displays according to embodiments of the present invention of how the user could provide feedback. First, as shown in FIG. 8A, the user could be presented with a screen where permissions are organized by types of permissions (e.g., location, contacts, messages, etc.) with an identification of the number of apps that request each type of permission. The user could then select one type of permission, which then causes the display to list the apps that request that type of permission, along with any recommendation by the PPA to possibly deny some of these permissions, if they are not yet denied. The reader will appreciate that a number of ways of presenting recommended permission settings are possible. In this particular embodiment, the user can then go through the recommended setting changes (e.g., recommendation to change the location permission requested by the PayPal app from “grant” to “deny” in FIG. 8B, or to change the (access) contacts permission from “grant” to “deny” for the CitiMobile app in FIG. 8C). In this particular embodiment, the user can accept or ignore each recommended setting change. In doing so, the user provides feedback to the PPA. This feedback can in turn be used to refine the user's Individual Privacy Preference model (step 2310 in FIG. 12). In this particular embodiment, the user can review each permission for each individual app as shown in the examples of FIGS. 8B (app requesting location) and 8C (apps requesting contacts), decide whether to accept or ignore different recommended settings, modify settings for which the PPA does not provide any recommendations, or modify earlier setting changes, including changes that may have been prompted by the PPA's recommendations. The permission settings control access by these technologies (e.g. apps on a computing device, IoT service, IoT app, IoT device, etc.) to sensitive data or functionality. An example is a set of permissions that enable a mobile operating system to control access to sensitive functionality or data by apps running on a smartphone (e.g., access to location tracking functionality, access to camera functionality, access to microphone functionality, access to messaging functionality, access to contacts list information, access to a device's unique identifier, access to health information, etc.). In another example, permissions control privacy and/or security settings associated with a browser or control which sensitive functionality or data websites can access. In yet another example, permissions may be used to capture and enforce user-specific settings associated with Internet of Things (IoT) devices or services such as opt-in or opt-out privacy settings associated with location tracking functionality in an office building, or permission to apply facial recognition functionality or scene recognition functionality to footage captured by a video monitoring system in a mall.).
However, it does not expressly teach the details of receiving, via the user software application installed on the at least one user device, user data comprising personal information of the user.
Prevost et al., from analogous art, teaches receiving, via the user software application installed on the at least one user device, user data comprising personal information of the user (See ¶¶ [0134]-[0135, Teaches that user device peripheral data is received via an entity software application (606). In some implementations, the peripheral data (e.g., contextual data 510 as described in relation to FIG. 5) may be polled prior to service of an event to the user of the user device. For example, geolocation information may be polled prior to service of an event, such that one or more contextual events, contextual features, and/or workflow steps may be added to the event. In some implementations, the peripheral data may be collected upon service of information associated with an event to the user. The peripheral data, for example, may be included within a response from the user to information issued by the multi-channel communication environment on behalf of the entity. The peripheral data, in some implementations, may be provided by a multi-channel sub-application of an entity software application, such as the multi-channel sub-application 506 described in relation to FIG. 5. For example, upon an event (e.g., launching of the entity software application, using an eWallet account via the entity software application, etc.), the multi-channel sub-application may provide peripheral data to the multi-channel communication environment. In another example, while the multi-channel sub-application is active, the multi-channel sub-application may collect peripheral data and provide it (e.g., on a periodic and/or event-driven basis) to the multi-channel communication environment. The peripheral data, in some implementations, is stored by the multi-channel communication environment. For example, a portion of the peripheral data may be collected for managing event service and/or transaction history by the entity, and/or for establishing behavior patterns of the user. The peripheral data, for example, may be stored within the user profile data store 124, as described in relation to FIG. 5.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Prevost et al. into Sadeh et al. in order to determine a communication channel for delivering information associated with the event to the first user (See Prevost et al. ¶ [0005]).
Claim 7 rejected under 35 U.S.C. 103 as being unpatentable over Sadeh et al. (US 20190108353 A1) and Prevost et al. (US 20130191481 A1) and further in view of Routson (US 20070192121 A1).
As to claim 7, the combination of Sadeh et al. and Prevost et al. teaches the system according to claim 1 above. However, it does not expressly teach the details of wherein at least one of the verbal interaction preferences is received from a telephone call center.
Routson, from analogous art, teaches wherein at least one of the verbal interaction preferences is received from a telephone call center (See ¶¶ [0035], Teaches that a transaction card customer service representative is able to opt-out customer 102 from outbound telemarketing and e-mail for the transaction card. However, the transaction card customer service representative may not be able to process the request to opt-out of sweepstakes offers because, for example, sweepstakes offers are controlled by a different business unit. Consequently, the transaction card customer service representative communicates to customer 102 that publishing and financial advisor representatives may handle the sweepstakes opt-outs. The transaction card customer service representative may also inform customer 102 that the sweepstakes opt-out can only be processed as a complete direct mail opt-out. Thus, if customer 102 does not want sweepstakes offers, customer 102 must also forego receiving any other direct mail offers from the transaction card company, which may not be a desirable solution to the customer.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Routson into the combination of Sadeh et al. and Prevost et al. in order to managing customer privacy and to managing customer preferences across multiple accounts (See Routson ¶ [0003]).
Claims 9-12 are rejected under 35 U.S.C. 103 as being unpatentable over Sadeh et al. (US 20190108353 A1) and Prevost et al. (US 20130191481 A1) and further in view of Bouse et al. (US 20120109882 A1).
As to claim 9, the combination of Sadeh et al. and Prevost et al. teaches the system according to claim 1 above. However, it does not expressly teach the details of wherein at least one of the verbal interaction preferences is an opt out of automatic decision making.
Bouse et al., from analogous art, teaches wherein at least one of the verbal interaction preferences is an opt out of automatic decision making (See ¶¶ [0088]-[0092], Teaches that the system at least allows Users to establish a interaction profile without capturing or storing any data that would jeopardize the User identity theft. The system requires no User credit card, no security questions used by credit bureaus or other consumer data aggregation companies (e.g. mother's maiden name, city of birth, etc.) Rather, Users are given the opportunity to establish their own security question and answer for password recovery. As an extra level of security, the User may, at their discretion opt in for a security password to use with customer service to be required for any account changes made via phone with a customer care representative. Likewise advantageously, as an option, the system at least allows Users to store credit card or banking information Users would like to be able to propagate amongst multiple Provisioners in one transaction. A use case for this type of functionality would be when a credit or debit card expires, and multiple “auto bill” Provisioners require the new, unexpired card information. Examples of “auto bill” Provisioners include Internet access companies such as Verizon, cell-phone companies such as AT&T, value-added consumer services such as NetFlix and EZ-Pass, utility companies such as PG&E, gym memberships, hotel chains, and more. The User may, at their option, push a card number with associated expiry and security numbers, to those Provisioners that store the User's financial data. Achieving customer intimacy is the ultimate desire of every Provisioner because by knowing more about stakeholders, Provisioners can create greater affinity between the User and the brand/or content. Also, Provisioners better identify and segment Users for their campaigns and give them additional levels of User insight. In summary, at least some embodiments of the system described herein allow the User to develop, at their discretion, the emotional/affinity that Provisioner crave, because information is shared willingly with Provisioners. Simultaneously, Provisioners are better able to learn more information about their Users in a way that allows them to enhance the customer experience.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bouse et al. into the combination of Sadeh et al. and Prevost et al. in order to both simplify and control the profile creation and management process while gaining control over what data and in what circumstances the User wants to share information with Provisioners (See Bouse et al. ¶ [0005]).
As to claim 10, the combination of Sadeh et al. and Prevost et al. teaches the system according to claim 1 above. However, it does not expressly teach the details of wherein at least one of the verbal interaction preferences is an opt out of affiliate sharing.
Bouse et al., from analogous art, teaches wherein at least one of the verbal interaction preferences is an opt out of affiliate sharing (See ¶¶ [0088]-[0092], Teaches that the system at least allows Users to establish a interaction profile without capturing or storing any data that would jeopardize the User identity theft. The system requires no User credit card, no security questions used by credit bureaus or other consumer data aggregation companies (e.g. mother's maiden name, city of birth, etc.) Rather, Users are given the opportunity to establish their own security question and answer for password recovery. As an extra level of security, the User may, at their discretion opt in for a security password to use with customer service to be required for any account changes made via phone with a customer care representative. Likewise advantageously, as an option, the system at least allows Users to store credit card or banking information Users would like to be able to propagate amongst multiple Provisioners in one transaction. A use case for this type of functionality would be when a credit or debit card expires, and multiple “auto bill” Provisioners require the new, unexpired card information. Examples of “auto bill” Provisioners include Internet access companies such as Verizon, cell-phone companies such as AT&T, value-added consumer services such as NetFlix and EZ-Pass, utility companies such as PG&E, gym memberships, hotel chains, and more. The User may, at their option, push a card number with associated expiry and security numbers, to those Provisioners that store the User's financial data. Achieving customer intimacy is the ultimate desire of every Provisioner because by knowing more about stakeholders, Provisioners can create greater affinity between the User and the brand/or content. Also, Provisioners better identify and segment Users for their campaigns and give them additional levels of User insight. In summary, at least some embodiments of the system described herein allow the User to develop, at their discretion, the emotional/affinity that Provisioner crave, because information is shared willingly with Provisioners. Simultaneously, Provisioners are better able to learn more information about their Users in a way that allows them to enhance the customer experience.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bouse et al. into the combination of Sadeh et al. and Prevost et al. in order to both simplify and control the profile creation and management process while gaining control over what data and in what circumstances the User wants to share information with Provisioners (See Bouse et al. ¶ [0005]).
As to claim 11, the combination of Sadeh et al. and Prevost et al. teaches the system according to claim 1 above. However, it does not expressly teach the details of wherein at least one of the verbal interaction preferences is an opt out of third party sharing.
Bouse et al., from analogous art, teaches wherein at least one of the verbal interaction preferences is an opt out of third party sharing (See ¶¶ [0088]-[0092], Teaches that the system at least allows Users to establish a interaction profile without capturing or storing any data that would jeopardize the User identity theft. The system requires no User credit card, no security questions used by credit bureaus or other consumer data aggregation companies (e.g. mother's maiden name, city of birth, etc.) Rather, Users are given the opportunity to establish their own security question and answer for password recovery. As an extra level of security, the User may, at their discretion opt in for a security password to use with customer service to be required for any account changes made via phone with a customer care representative. Likewise advantageously, as an option, the system at least allows Users to store credit card or banking information Users would like to be able to propagate amongst multiple Provisioners in one transaction. A use case for this type of functionality would be when a credit or debit card expires, and multiple “auto bill” Provisioners require the new, unexpired card information. Examples of “auto bill” Provisioners include Internet access companies such as Verizon, cell-phone companies such as AT&T, value-added consumer services such as NetFlix and EZ-Pass, utility companies such as PG&E, gym memberships, hotel chains, and more. The User may, at their option, push a card number with associated expiry and security numbers, to those Provisioners that store the User's financial data. Achieving customer intimacy is the ultimate desire of every Provisioner because by knowing more about stakeholders, Provisioners can create greater affinity between the User and the brand/or content. Also, Provisioners better identify and segment Users for their campaigns and give them additional levels of User insight. In summary, at least some embodiments of the system described herein allow the User to develop, at their discretion, the emotional/affinity that Provisioner crave, because information is shared willingly with Provisioners. Simultaneously, Provisioners are better able to learn more information about their Users in a way that allows them to enhance the customer experience.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bouse et al. into the combination of Sadeh et al. and Prevost et al. in order to both simplify and control the profile creation and management process while gaining control over what data and in what circumstances the User wants to share information with Provisioners (See Bouse et al. ¶ [0005]).
As to claim 12, the combination of Sadeh et al. and Prevost et al. teaches the system according to claim 1 above. However, it does not expressly teach the details of wherein at least one of the verbal interaction preferences is an opt out of marketing verbal interactions for one or more telephone numbers of the user.
Bouse et al., from analogous art, teaches wherein at least one of the verbal interaction preferences is an opt out of marketing verbal interactions for one or more telephone numbers of the user (See ¶¶ [0088]-[0092], Teaches that the system at least allows Users to establish a interaction profile without capturing or storing any data that would jeopardize the User identity theft. The system requires no User credit card, no security questions used by credit bureaus or other consumer data aggregation companies (e.g. mother's maiden name, city of birth, etc.) Rather, Users are given the opportunity to establish their own security question and answer for password recovery. As an extra level of security, the User may, at their discretion opt in for a security password to use with customer service to be required for any account changes made via phone with a customer care representative. Likewise advantageously, as an option, the system at least allows Users to store credit card or banking information Users would like to be able to propagate amongst multiple Provisioners in one transaction. A use case for this type of functionality would be when a credit or debit card expires, and multiple “auto bill” Provisioners require the new, unexpired card information. Examples of “auto bill” Provisioners include Internet access companies such as Verizon, cell-phone companies such as AT&T, value-added consumer services such as NetFlix and EZ-Pass, utility companies such as PG&E, gym memberships, hotel chains, and more. The User may, at their option, push a card number with associated expiry and security numbers, to those Provisioners that store the User's financial data. Achieving customer intimacy is the ultimate desire of every Provisioner because by knowing more about stakeholders, Provisioners can create greater affinity between the User and the brand/or content. Also, Provisioners better identify and segment Users for their campaigns and give them additional levels of User insight. In summary, at least some embodiments of the system described herein allow the User to develop, at their discretion, the emotional/affinity that Provisioner crave, because information is shared willingly with Provisioners. Simultaneously, Provisioners are better able to learn more information about their Users in a way that allows them to enhance the customer experience.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Bouse et al. into the combination of Sadeh et al. and Prevost et al. in order to both simplify and control the profile creation and management process while gaining control over what data and in what circumstances the User wants to share information with Provisioners (See Bouse et al. ¶ [0005]).
Claims 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Sadeh et al. (US 20190108353 A1) and Prevost et al. (US 20130191481 A1) and further in view of Wright et al. (US 9894050 B1).
As to claim 13, the combination of Sadeh et al. and Prevost et al. teaches the system according to claim 1 above. However, it does not expressly teach the details of wherein the dashboard is a personal dashboard when the user data received by the computer is authenticated.
Wright et al., from analogous art, teaches wherein the dashboard is a personal dashboard when the user data received by the computer is authenticated (See Col 13 Ln 1, Col 14 Ln 35, Teaches that referring to FIG. 4, the settings menu 402 can display settings 406, 408, and 410. The settings menu 402 can display preferences 412a-c for on startup setting 406, preferences 414a-b for an appearance setting 408, and preferences 416a-b for a downloads setting 410. The front-end application 164 can access the settings/preferences file associated with the user and included in the settings/preferences files 150 to provide output to the settings menu 402 indicative of the stored preferences for the settings 406, 408 and 410 for the authenticated user. As shown in FIG. 5, the unauthenticated user may opt to sign in by selecting a sign in button 530. For example, the web browser application can receive an indication of the selection of the sign in button 530. In response, the web browser application can display the user interface 200 as shown in FIG. 2A. The authentication process can then be similar as that described above with reference to FIGS. 2A-B. Once signed in and authenticated, referring now to FIGS. 3A-B, if the web browser application 210 receives the selection of the settings choice 308, the web browser application 210, and specifically the front-end application 164, can display the settings menu 402, as shown in the user interface 400 in FIG. 4. The authenticated user will be provided with selected settings and preferences and can input settings and preferences as described above with reference to FIG. 4.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Wright et al. into the combination of Sadeh et al. and Prevost et al. in order to cause the settings page to be displayed by the display device (See Wright et al. Col 1 Ln 61).
As to claim 14, the combination of Sadeh et al. and Prevost et al. teaches the system according to claim 1 above. However, it does not expressly teach the details of wherein the dashboard is a generic dashboard when the user data received by the computer is unauthenticated.
Wright et al., from analogous art, teaches wherein the dashboard is a generic dashboard when the user data received by the computer is unauthenticated (See Col 13 Ln 1, Col 14 Ln 35, Teaches that referring to FIG. 4, the settings menu 402 can display settings 406, 408, and 410. The settings menu 402 can display preferences 412a-c for on startup setting 406, preferences 414a-b for an appearance setting 408, and preferences 416a-b for a downloads setting 410. The front-end application 164 can access the settings/preferences file associated with the user and included in the settings/preferences files 150 to provide output to the settings menu 402 indicative of the stored preferences for the settings 406, 408 and 410 for the authenticated user. As shown in FIG. 5, the unauthenticated user may opt to sign in by selecting a sign in button 530. For example, the web browser application can receive an indication of the selection of the sign in button 530. In response, the web browser application can display the user interface 200 as shown in FIG. 2A. The authentication process can then be similar as that described above with reference to FIGS. 2A-B. Once signed in and authenticated, referring now to FIGS. 3A-B, if the web browser application 210 receives the selection of the settings choice 308, the web browser application 210, and specifically the front-end application 164, can display the settings menu 402, as shown in the user interface 400 in FIG. 4. The authenticated user will be provided with selected settings and preferences and can input settings and preferences as described above with reference to FIG. 4.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teaching of Wright et al. into the combination of Sadeh et al. and Prevost et al. in order to cause the settings page to be displayed by the display device (See Wright et al. Col 1 Ln 61).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
BODIN et al. (US 20200160377 A1) teaches The present disclosure relates to digital experience development platforms and, more particularly, one or more components, systems and methods thereof of an intelligent digital experience development platform (IDXDP) configured to assist different users in the development, design and deployment of digital applications. A computer-implemented method comprises: receiving, by a computing device of a cloud-based campaign system, a campaign for products or services from a marketing system via a network; providing, by the computing device, the campaign to one or more participants on the network; obtaining, by the computing device, feedback from the one or more participants regarding the campaign; analyzing, by an artificial intelligence tool of the computing device, the feedback to generate marketing analytics information; and providing, by the computing device, the marketing analytics information to the marketing system via the network.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to James R Hollister whose telephone number is (571)270-3152. The examiner can normally be reached Mon - Fri 7:30 am - 4:00 pm.
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, Philip Chea can be reached at (571) 272-3951. 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.
James Hollister
/J.R.H./Examiner, Art Unit 2499 9/18/26
/PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights