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 .
Response to Amendments / Arguments
Regarding the rejection(s) of claims under 35 USC 103:
Applicant’s arguments, filed 05/13/2026, have been fully considered and are not persuasive.
Applicant argues that the Firefox "How does it work?" image is not a permission user interface element because it is "an image of a push notification payload" that "does not ask for a decision." In response, it is noted that claim 1 does not require the loud user interface element to obtain a decision from the user. Claim 1 recites "generating a user interface for obtaining a decision from the user... the user interface including the intermediate user interface element". The decision obtaining function is attached solely to the intermediate user interface element, which is the element selected and rendered by the method. The loud user interface element is recited only as a member of the selection group and is defined only by its relative interruptiveness ("the intermediate user interface element is less interruptive to the user than the loud user interface element").
Applicant further argues for claim 21 and 22 the two thresholds must represent opposing grant/deny likelihoods, but that limitation appears nowhere in the claims. Claim 1 defines both thresholds as "different likelihoods of the user granting access". A single axis and claim 21 simply specifies a high point ("likely to grant") and a low point ("unlikely to grant") on that same axis. Sadeh's 90% and 70% are two different confidence points on one scale, which reads directly on "different likelihoods of granting," a high one and a low one. Applicant's "opposed confidence" distinction is not constructed within the claim language.
Therefore, the identified claim language is considered to be taught by the references combination, and the rejection is maintained. Further, since Applicant has not argued the other dependent claims, their rejections are likewise maintained.
DETAILED ACTION
This is a reply to the arguments filed on 05/13/2026, 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.
Applicant’s amendment necessitated the new ground(s) of rejection presented in this office action. Accordingly, THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to 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
Prosecution Insights