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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 10/14/2025 has been entered.
Response to Amendments / Arguments
Regarding the rejection(s) of claims under 35 USC 103:
Applicant’s arguments, filed 10/14/2025, in view of the amended claims, have been fully considered and are not persuasive.
Applicant argues that Sadeh's interface merely "recommends permission settings" while the claimed invention "obtains a decision from the user to allow permission for the resource or block access to the resource." This argument fundamentally mischaracterizes the Sadeh reference. Paragraph [0052] of Sadeh explicitly recites that "the recommended permission settings are presented to the user of the computing device and at step 2240 the permission settings can be configured based on feedback from the user, such as the user accepting, rejecting or modifying the recommended permission settings." Additionally, Figures 8A-C of Sadeh clearly illustrate user interfaces where users make explicit allow/deny decisions for individual app permissions. The examine finds that the act of "accepting, rejecting or modifying" permission settings teaches "obtaining a decision from the user to allow permission for the resource or block access to the resource."
Applicant argues that Sadeh fails to teach "determining that a user of the computing device has not blocked a website from accessing a resource of the computing device and has not allowed the website to access the resource." However, paragraphs [0036]-[0037] of Sadeh describe how "when a particular app 212 requests a particular functionality or data 140, 141, 150, 151, the operating system 210 may determine, based on the device's permissions settings, whether the app should be granted access to the functionality/data or not." The examiner finds that this teaches determining the current permission state, including scenarios where permissions are undecided (i.e., neither explicitly blocked nor allowed).
Applicant argues that Sadeh's thresholds serve different purposes than those claimed. However, paragraph [0070] of Sadeh teaches using "multiple thresholds...including a threshold above which a recommendation will be automatically enacted...and one where the recommendation will be used to prompt the user." The examiner finds this teaches using different confidence levels to determine user interaction approaches - precisely what the claimed thresholds accomplish in selecting UI element intrusiveness levels.
Applicant's argument against Firefox and Kelly that they deal with "post-permission notifications" rather than permission requests is not persuasive. Both Firefox and Kelly demonstrate interfaces for obtaining user permission to access device notification resources. Web push notifications require explicit user permission under standard browser security models, making these genuine permission decision interfaces. Firefox's notification permission interface and Kelly's "speech bubble" for notification access permissions are directly analogous to the claimed website resource permission interfaces. The combination of Sadeh's permission scoring system with Firefox/Kelly's different UI presentation modes (loud/intermediate/quiet notification styles) to create the claimed three-tier UI element selection represents an obvious design choice to one of ordinary skill in the art.
Therefore, the identified claim language is considered to be taught by the Sadeh-Fareh-Firefox-Kelly combination, and the rejection is maintained. Further, since Applicant has not presented additional arguments concerning the dependent claims, their rejections are likewise maintained.
DETAILED ACTION
This is a reply to the arguments filed on 10/14/2025, in which, claims 1-22 are pending. Claims 1 and 13 are independent.
When making claim amendments, the applicant is encouraged to consider the references in their entireties, including those portions that have not been cited by the examiner and their equivalents as they may most broadly and appropriately apply to any particular anticipated claim amendments.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-22 are rejected under 35 U.S.C. 103 as being unpatentable over Sadeh et al. (US 20210319122 A1, referred to as Sadeh), in view of Farah (US 20160269412 A1, referred to as Farah) in further view of Firefox (“Web Push notifications in Firefox”, referred to as Firefox) in further view of Kelly (“Say goodbye to annoying notification requests”, referred to as Kelly).
In reference to claim 1, A computer-implemented method performed on a computing device, the computer-implemented method comprising (Sadeh: [0023] Provides for computer-implemented methods on computing devices for managing permissions and user interactions with technology resources.)
Determining that a user of the computing device has not blocked a system from accessing a resource of the computing device and has not allowed the system to access the resource (Sadeh: [0004], [0024]-[0027] and [0036]-[0037] Provides for scenarios where users haven't made explicit permission decisions.)
Obtaining a permission score for access to the resource from a model (Sadeh: [0027] and [0068]-[0070] Provides for obtaining permission scores/recommendations from models that predict user preferences for granting access to resources.
Determining that the permission score fails to meet a first threshold and fails to meet a second threshold the first threshold and the second threshold representing different likelihoods of the user granting access to the resource (Sadeh: [0070]-[0074] Provides for using multiple thresholds to determine different levels of confidence in permission recommendations.
In response to determining that the permission score fails to meet the first threshold and fails to meet the second threshold, selecting an intermediate user interface element (Sadeh: [0030] Provides for UI elements based on confidence levels, with the prior art describing different forms of user interface nudges.)
From among different user interface elements (Sadeh: [0045] and [0073] Provides for different notification modalities and presentation approaches.)
Generating a user interface for obtaining a decision from the user to allow permission for the resource or block access to the resource on a display of the computing device, ther user interface including the intermediate user interface element (Sadeh: [0046] Provides for generating user interfaces on computing device displays that include privacy-related interface elements to guide user permission decisions.)
Sadeh does not explicitly disclose that the system is a website however Farah teaches:
Wherein the system is a website (Farah: [0046]- [0047] Provides for a state where a website is neither explicitly allowed nor explicitly blocked.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sadeh, which provides a computer-implemented method for managing permissions and user interactions with technology resources using predictive models and threshold-based UI selection, with the teachings of Farah, which introduces website-specific permission management scenarios. One of ordinary skill in the art would recognize the ability to apply Sadeh's permission scoring and interface selection methodology to website permission requests. One of ordinary skill in the art would be motivated to make this modification in order to improve user experience on websites by providing intelligent permission prompts based on predicted user preferences.
Sadeh in view of Farah does not explicitly disclose the difference between a intermediate user interface and a loud interface element. However, Firefox discloses:
Wherein one of the different user interface elements is a loud interface element and Wherein the intermediate user interface element is less interruptive to the user than a loud user interface element (Firefox: “Image above table of contents” Provides for an intermediate user interface element that drops down and asks the user if website would be allowed to send notifications. Firefox “How does it work” Provides for a loud user interface element that isn’t just a drop down but pops onto the users screen being more intrusive.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sadeh in view of Farah, which provides website permission management using predictive scoring and interface selection, with the teachings of Firefox, which introduces different levels of user interface intrusiveness including intermediate and loud interface elements. One of ordinary skill in the art would recognize the ability to incorporate Firefox's graduated interface approach into the permission management system to provide more nuanced user interaction options. One of ordinary skill in the art would be motivated to make this modification in order to balance user awareness with minimal disruption by providing interface options that match the urgency and importance of permission requests.
Sadeh in view of Farah in view of Firefox does not explicitly disclose a quiet user interface element. However, Kelly teaches:
Wherein one of the different user interface elements is a quiet user interface element and The intermediate user interface element is more interruptive than quiet user interface element (Kelly: “GIF Image above paragraph starting with ‘once you’ve made your choice..’” Provides for a quiet user interface element that will only show a speech bubble in the URL bar that would be required to click to grant further permissions.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sadeh in view of Farah and Firefox, which together provide website permission management with graduated interface intrusiveness levels, with the teachings of Kelly, which introduces a quiet user interface element for minimal user disruption. One of ordinary skill in the art would recognize the ability to incorporate Kelly's quiet interface option to complete the spectrum of interface choices available in the permission management system. One of ordinary skill in the art would be motivated to make this modification in order to provide a complete range of interface options from subtle to prominent.
In reference to claim 2, The computer-implemented method of claim 1, wherein the model uses features about the website and features about past actions of the user on permission prompts to generate the permission score (Sadeh: [0028] and [0067]-[0071] Provides for using both features about the requesting entity (app categories, which are analogous to website features) and features about past user actions (accepts, rejects, modifies permission recommendations) to generate likelihood scores for permission decisions.)
In reference to claim 3, The computer-implemented method of claim 1, wherein the model uses features about past actions of the user on permission prompts to generate the permission score (Sadeh: [0028] and [0056]-[0060] Provides for using past user actions on permission prompts (accepts, rejects, modifies) to refine individual privacy preference models and generate future likelihood scores.)
In reference to claim 4, The computer-implemented method of claim 1, wherein the model uses features about the website to generate the permission score (Sadeh: [0044]-[0048] and [0068] Provides for using features about the requesting entity (app categories like "game apps, utility apps, social networking apps") to generate likelihood scores for permission decisions.)
In reference to claim 5, The computer-implemented method of claim 1, wherein the loud user interface element occupies more area of the display when displayed than the intermediate user interface element, and the intermediate user interface element occupies more area of the display when displayed than the quiet user interface element (Firefox: “Image above table of contents” Provides for an intermediate user interface element that drops down and asks the user if website would be allowed to send notifications. Firefox “How does it work” Provides for a loud user interface element that isn’t just a drop down but pops onto the users screen being more intrusive and is larger than the intermediate interface element. Kelly “Image above paragraph starting with ‘once you’ve made your choice..’” Provides for a quiet user interface element that will only show a speech bubble in the URL bar (which is smaller than both the loud UI and intermediate UI) that would be required to click to grant further permissions.)
In reference to claim 6, The computer-implemented method of claim 1, wherein the intermediate user interface element and the loud user interface element include a selectable area for allowing permission for the resource (Firefox: “Image above table of contents” Provides for a selectable area to allow the permission of the resource. Firefox “How does it work” Provides for a selectable area that would open further settings to allow the resource.)
In reference to claim 7, The computer-implemented method of claim 1, wherein the intermediate user interface element is an animated element that causes at least one other browser-based user interface element to at least temporarily be displaced (Firefox: “Image above table of contents” Provides for a drop down element in the intermediate user interface.)
In reference to claim 8, The computer-implemented method of claim 1, wherein when displayed the loud user interface element overlays at least some content of the website and the intermediate user interface element shares an area of the display previously occupied by at least one browser-based user interface element (Firefox: Firefox: “Image above table of contents” Provides for the intermediate user interface element being extended on to the text of the website which can be applied to the loud UI as well. Firefox “How does it work” Provides for a notification pop up occupying space on the browser based interface.)
In reference to claim 9, The computer-implemented method of claim 1, wherein when displayed the quiet user interface element is initially an icon without text and the intermediate user interface element is initially an icon with text (Kelly: “Image above paragraph starting with ‘once you’ve made your choice..’” Provides for a quiet user interface element that will only show a speech bubble in the URL bar (which is smaller than both the loud UI and intermediate UI) that would be required to click to grant further permissions. Firefox “Image above table of contents” Provides for the intermediate user interface being an icon with a drop down of text.)
In reference to claim 10, The computer-implemented method of claim 9, wherein placement of the intermediate user interface element is based on a reading direction (Firefox: “image above table of contents” Provides for a notification that is on the left side of the screen for English readers.)
In reference to claim 11, The computer-implemented method of claim 1, wherein the model takes as input a form factor of the computing device, aggregate statistics representing number of times permission for the resource is blocked, aggregate statistics representing number of times permission for the resource is allowed, and user-based statistics relating to permission for the resource for the user of the computing device (Sadeh: [0026]-[0028], [0048] and [0067] Provides for different device types (desktop, laptop, tablet, wearable, smart TV, etc.), further provides for clustering users based on permission grant/deny patterns and threshold percentages of users agreeing on permission settings, even further provides for individual user preference models based on user's past actions on permissions.)
In reference to claim 12, The computer-implemented method of claim 1, wherein the intermediate user interface element includes a selectable element that initiates a privacy settings user interface (Firefox: Image above table of contents” Provides for the intermediate user interface element including a selectable “learn more” setting.)
In reference to claim 13, A computing device comprising: at least one processor; and memory storing instructions that, when executed by the at least one processor, causes the computing device to perform operations including (Sadeh: [0023] Provides for computer-implemented methods on computing devices for managing permissions and user interactions with technology resources.)
Determining that a user of the computing device has not blocked a system from accessing a resource of the computing device and has not allowed the system to access the resource (Sadeh: [0004] and [0024]-[0027] Provides for scenarios where users haven't made explicit permission decisions.)
Obtaining a permission score for access to the resource from a model (Sadeh: [0027] and [0068]-[0070] Provides for obtaining permission scores/recommendations from models that predict user preferences for granting access to resources.
Determining that the permission score fails to meet a first threshold and fails to meet a second threshold the first threshold and the second threshold representing different likelihoods of the user granting access to the resource (Sadeh: [0070]-[0074] Provides for using multiple thresholds to determine different levels of confidence in permission recommendations.
In response to determining that the permission score fails to meet the first threshold and fails to meet the second threshold, selecting an intermediate user interface element (Sadeh: [0030] Provides for UI elements based on confidence levels, with the prior art describing different forms of user interface nudges.)
From among different user interface elements (Sadeh: [0045] and [0073] Provides for different notification modalities and presentation approaches.)
Generating a user interface for obtaining a decision from the user to allow permission for the resource or block access to the resource on a display of the computing device, ther user interface including the intermediate user interface element (Sadeh: [0046] Provides for generating user interfaces on computing device displays that include privacy-related interface elements to guide user permission decisions.)
Sadeh does not explicitly disclose that the system is a website however Farah teaches:
Wherein the system is a website (Farah: [0046]- [0047] Provides for a state where a website is neither explicitly allowed nor explicitly blocked.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sadeh, which provides a computer-implemented method for managing permissions and user interactions with technology resources using predictive models and threshold-based UI selection, with the teachings of Farah, which introduces website-specific permission management scenarios. One of ordinary skill in the art would recognize the ability to apply Sadeh's permission scoring and interface selection methodology to website permission requests. One of ordinary skill in the art would be motivated to make this modification in order to improve user experience on websites by providing intelligent permission prompts based on predicted user preferences.
Sadeh in view of Farah does not explicitly disclose the difference between a intermediate user interface and a loud interface element. However, Firefox discloses:
Wherein one of the different user interface elements is a loud interface element and Wherein the intermediate user interface element is less interruptive to the user than a loud user interface element (Firefox: “Image above table of contents” Provides for an intermediate user interface element that drops down and asks the user if website would be allowed to send notifications. Firefox “How does it work” Provides for a loud user interface element that isn’t just a drop down but pops onto the users screen being more intrusive.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sadeh in view of Farah, which provides website permission management using predictive scoring and interface selection, with the teachings of Firefox, which introduces different levels of user interface intrusiveness including intermediate and loud interface elements. One of ordinary skill in the art would recognize the ability to incorporate Firefox's graduated interface approach into the permission management system to provide more nuanced user interaction options. One of ordinary skill in the art would be motivated to make this modification in order to balance user awareness with minimal disruption by providing interface options that match the urgency and importance of permission requests.
Sadeh in view of Farah in view of Firefox does not explicitly disclose a quiet user interface element. However, Kelly teaches:
Wherein one of the different user interface elements is a quiet user interface element and The intermediate user interface element is more interruptive than quiet user interface element (Kelly: “GIF Image above paragraph starting with ‘once you’ve made your choice..’” Provides for a quiet user interface element that will only show a speech bubble in the URL bar that would be required to click to grant further permissions.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Sadeh in view of Farah and Firefox, which together provide website permission management with graduated interface intrusiveness levels, with the teachings of Kelly, which introduces a quiet user interface element for minimal user disruption. One of ordinary skill in the art would recognize the ability to incorporate Kelly's quiet interface option to complete the spectrum of interface choices available in the permission management system. One of ordinary skill in the art would be motivated to make this modification in order to provide a complete range of interface options from subtle to prominent.
In reference to claim 14, The computing device of claim 13, wherein to generate the permission score the model uses features about the website or features about past actions of the user on permission prompts (Sadeh: [0028] and [0067]-[0071] Provides for using both features about the requesting entity (app categories, which are analogous to website features) and features about past user actions (accepts, rejects, modifies permission recommendations) to generate likelihood scores for permission decisions.)
In reference to claim 15, The computing device of claim 13, wherein the loud user interface element occupies more area of the display when displayed than the intermediate user interface element, and the intermediate user interface element occupies more area of the display when displayed than the quiet user interface element (Firefox: “Image above table of contents” Provides for an intermediate user interface element that drops down and asks the user if website would be allowed to send notifications. Firefox “How does it work” Provides for a loud user interface element that isn’t just a drop down but pops onto the users screen being more intrusive and is larger than the intermediate interface element. Kelly “Image above paragraph starting with ‘once you’ve made your choice..’” Provides for a quiet user interface element that will only show a speech bubble in the URL bar (which is smaller than both the loud UI and intermediate UI) that would be required to click to grant further permissions.)
In reference to claim 16, The computing device of claim 13, wherein the intermediate user interface element is an animated element that causes at least one other browser-based user interface element to at least temporarily be displaced (Firefox: “Image above table of contents” Provides for a drop down element in the intermediate user interface.)
In reference to claim 17, The computing device of claim 13, wherein when displayed the loud user interface element overlays at least some content of the website and the intermediate user interface element shares an area of the display previously occupied by at least one browser-based user interface element (Firefox: Firefox: “Image above table of contents” Provides for the intermediate user interface element being extended on to the text of the website which can be applied to the loud UI as well. Firefox “How does it work” Provides for a notification pop up occupying space on the browser based interface.)
In reference to claim 18, The computing device of claim 13, wherein when displayed the quiet user interface element is initially an icon without text and the intermediate user interface element is initially an icon with text (Kelly: “Image above paragraph starting with ‘once you’ve made your choice..’” Provides for a quiet user interface element that will only show a speech bubble in the URL bar (which is smaller than both the loud UI and intermediate UI) that would be required to click to grant further permissions. Firefox “Image above table of contents” Provides for the intermediate user interface being an icon with a drop down of text.)
In reference to claim 19, The computing device of claim 13, wherein the model takes as input a form factor of the computing device, aggregate statistics representing number of times permission for the resource is blocked, aggregate statistics representing number of times permission for the resource is allowed, and user-based statistics relating to permission for the resource for the user of the computing device (Sadeh: [0026]-[0028], [0048] and [0067] Provides for different device types (desktop, laptop, tablet, wearable, smart TV, etc.), further provides for clustering users based on permission grant/deny patterns and threshold percentages of users agreeing on permission settings, even further provides for individual user preference models based on user's past actions on permissions.)
In reference to claim 20, The computing device of claim 13, wherein the intermediate user interface element includes a selectable element that initiates a privacy settings user interface (Firefox: Image above table of contents” Provides for the intermediate user interface element including a selectable “learn more” setting.)
In reference to claim 21, the computer-implemented method of claim 1, wherein the first threshold indicates the user is likely to grant access to the resource and second threshold indicates the user in unlikely to grant access to the resource (Sadeh: [0070] Provides for using multiple thresholds to determine different confidence levels for permission recommendations. The 90% threshold for automatic enactment corresponds to high likelihood of granting/denying access, while the 70% threshold for prompting the user represents lower confidence.)
In reference to claim 22, The computing device of claim 13, wherein the first threshold indicated a high likelihood of the user granting permission to access the resource and the second threshold indicates a high likelihood of the user denying permission to access the resource (Sadeh: [0070] Provides for using multiple thresholds to determine different confidence levels for permission recommendations. The 90% threshold for automatic enactment corresponds to high likelihood of granting/denying access, while the 70% threshold for prompting the user represents lower confidence.)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. See PTO-892.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AIDAN EDWARD SHAUGHNESSY whose telephone number is (703)756-1423. The examiner can normally be reached on Monday-Friday from 7:30am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Jeffrey Nickerson, can be reached at telephone number (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/usptoautomated-interview-request-air-form.
/A.E.S./Examiner, Art Unit 2432
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432