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 .
Detailed action
Claims 1-6 and 8-20 are pending and being considered.
Claims 1, 2, 5, 6, 8, 10-13 and 15-20 have been amended.
Claim 7 have been cancelled.
Claim 21 have been newly added.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 05/18/2026 was filed after the mailing date of the application no. 18/905198. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Objections
Claim 15 objected to because of the following informalities:
Claim 15 recites “further further” delete the duplicate. Appropriate correction is required.
Response to 102/103
Applicant’s arguments filed on 05/18/2026 have been fully considered and are not persuasive.
In response to applicant’s argument on page 12-13 of remarks that the cited prior art Cohen fails to explicitly teach the amended limitation “ based on the at least one user input, modifying, via the application server, a HyperText Markup Language (“HTML”) associated with the first content element to remove the accessibility element, wherein modifying the HTML associated with the first DRM-protected content element to remove the accessibility element includes removing an Accessible Rich Internet Applications (“ARIA”) from a Document Object Model (“DOM”) of the HTML” the applicant argues that Cohan fails to teach modifying HTML based on user input. The examine respectfully disagrees because Cohen [0076-0077] explicitly teaches the DOM may interface between the JavaScript engine of the browser application and the webpage document allowing to dynamically add, change, and remove HTML elements and attributes, change CSS style definitions, react to event, and create new events. An event may refer to or include an action or occurrence, indicated or represented by data, that may cause a change of state in a runtime environment, wherein events may include user interface actions (e.g., a mouse click or keyboard entry). See on [0104-0105] teaches change in HTML triggered by user input. See on [0238] teaches modifying the content (e.g., in response to an input event). See on [0583-0595] teaches removing sensitive data in the DOM based on event by user.
Next, the applicant further argues that the prior art Page fails to teach modifying the HTML element to remove ARIA element based on user input. The examiner respectfully disagrees because first, Cohan already discloses modifying HTML based on user input as explained above. Second, the prior art Page on [0267-0268] discloses one or more attributes that provide accessible names to one or more elements may be removed such as, for example, aria-label and/or aria-labelledby attributes. In some embodiments, web developers often place ARIA attributes purposely, and removing attributes may decrease accessibility. Further teaches one or more ARIA attributes may be substituted or removed. See also on [0274] discloses one or more labels may be disassociated from one or more inputs by, for example, removing one or more “for” attributes.
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.
Claims 1-6 and 8-9 are rejected under 35 U.S.C. 103 as being unpatentable over Cohen (US 20240403413) in view of Page et al (hereinafter Page) (US 20220121723).
Regarding claim 1 Cohen teaches a method for obfuscating an accessibility element using digital rights management (“DRM”) protections, the method comprising: (Cohen on [0016] teaches method for masking sensitive data, thereby generating a masked version of the sensitive data and concealing the at least a portion of the unmasked version of the sensitive data when content is displayed);
determining, via an application server, the accessibility element is associated with a first DRM-protected content element (Cohen on [0397] teaches upon intercepting a request for sensitive data, an agent may analyze and parse the request to determine an element associated with the requested sensitive data (i.e., accessibility element). For example, the request may be formulated as an API invocation referencing an element associated with sensitive data (i.e., operation can be performed with server [0084]). See on [0381] teaches sensitive data associated with at least one element may refer to sensitive data that is configured at least in part by the at least one element (e.g., as an assignment of sensitive data to a data container, a setting to format sensitive data, and/or an invocation to access sensitive data), sensitive data for which the at least one element (e.g., in a code) is configured to enable the display of, or sensitive data that is influenced by the at least one element. See on [0594] teaches identify the sensitive data based on an indicator; access a Document Object Model (DOM) associated with the code; identify, in the DOM, an unmasked version of the sensitive data. See on [0597-0607] teaches wherein the sensitive data is associated with at least one element associated with the code, and wherein identifying in the DOM the unmasked version of the sensitive data includes identifying the at least one element in the DOM, wherein the at least one element includes a hypertext markup language (HTML) element);
obtaining, via the application server at least one user input associated with the accessibility element or the first content DRM-protected element (Cohen on [0076-0079] teaches receiving via graphical user interface a click event from user associated with specific webpage element. See on [0381] teaches receiving via user interface input associated with sensitive data, the sensitive data is associated with at least one element associated with the code. An element associated with a code (e.g., a web element) may refer to a distinct section of code (e.g., HTML, CSS, and/or JavaScript code) associated with a webpage (e.g., corresponding to a section of a webpage). For instance, the at least one element may include a hypertext markup language (HTML) element. An HTML element may a portion of an HTML code delineated with at least one tag (e.g., “<” and “>”));
wherein the at least one user input includes at least one of hovering, selecting, or clicking, wherein the at least one user input has been obtained via a first graphical user interface ("GUI") of a first user device; (Cohen on [0077] teaches events may include user interface actions (e.g., a mouse click or keyboard entry). See on [0104-0105 and 0119] teaches the user input may include at least one of: a computer mouse gesture, a gesture on a touch screen, a cursor movement, or a key press);
based on the at least one user input, modifying, via the application server, a HyperText Markup Language (“HTML”) associated with the first DRM-protected content element to remove the accessibility element (Cohen on [0076-0077] teaches the DOM may interface between the JavaScript engine of the browser application and the webpage document allowing to dynamically add, change, and remove HTML elements and attributes, change CSS style definitions, react to event, and create new events. See on [0525-0527] teaches replacing the at least one encoded runtime parameter, wherein the at least one runtime parameter includes a Hypertext Markup Language (HTML) string. See on [0594] teaches replace in the DOM at least a portion of the unmasked version of the sensitive data with a mask, thereby generating a masked version of the sensitive data and concealing the at least a portion of the unmasked version of the sensitive data when content is displayed based on the code. See on [0104-0105] teaches change in HTML triggered by user input. See on [0238] teaches modifying the content (e.g., in response to an input event). See on [0583-0595] teaches removing sensitive data in the DOM based on event by user);
and causing to output, via the first GUI, the modified first DRM-protected content element such that the accessibility element is no longer caused to be output (Cohen on [0401-0402 and 0593-0595] teaches replace in the DOM at least a portion of the unmasked version of the sensitive data with a mask, thereby generating a masked version of the sensitive data and concealing the at least a portion of the unmasked version of the sensitive data when content is displayed based on the code and preventing display of the at least a portion of the unmasked version of the sensitive data. See on [0377 and 0394] teaches an agent 9-110 (e.g., corresponding to cybersecurity agent 226) may provide a virtual barrier between code 9-108 and DOM 9-106, preventing a display of sensitive data 9-104 included in code 9-108 without affecting integrity (e.g., maintaining integrity) of sensitive data 9-104 in code 9-108. Agent 9-110 may identify sensitive data 9-104 in code 9-108, for instance, by scanning code 9-108 (e.g., and/or a runtime version of code 9-108, such as DOM 9-106) to detect one or more contextual character sequences, such as a declaration for an HTML div element 9-112, including an identifier 9-114 (e.g., “credit card”) and sensitive data 9-104).
Cohan fails to explicitly teach removing ARIA elements, however Page from analogous art teaches
wherein modifying the HTML associated with the first DRM-protected content element to remove the accessibility element includes removing an Accessible Rich Internet Application ("ARIA") from a Document Object Model ("DOM") of the HTML (Page on [0267-0268] discloses one or more attributes that provide accessible names to one or more elements may be removed such as, for example, aria-label and/or aria-labelledby attributes. In some embodiments, web developers often place ARIA attributes purposely, and removing attributes may decrease accessibility. Further teaches one or more ARIA attributes may be substituted or removed. See also on [0274] discloses one or more labels may be disassociated from one or more inputs by, for example, removing one or more “for” attributes).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Page into the teaching of Cohen by removing an Accessible Rich Internet Applications (“ARIA”) from a Document Object Model. One would be motivated to do so in order to facilitate enhanced accessibility of website (Page [0008]).
Regarding claim 2 the combination of Cohen and Page teaches all the limitations of claim 1 above, Cohen further teaches obtaining, via the application server a determination whether digital extraction is indicated from a browser module and upon obtaining the determination that the digital extraction is indicated modifying the HTML associated with the first DRM- protected content element to remove the accessibility element via the application server (Cohen on [0076-0077] teaches the DOM may interface between the JavaScript engine of the browser application and the webpage document allowing to dynamically add, change, and remove HTML elements and attributes, change CSS style definitions, react to event, and create new events. See on [0525-0527] teaches replacing the at least one encoded runtime parameter, wherein the at least one runtime parameter includes a Hypertext Markup Language (HTML) string. See on [0594] teaches replace in the DOM at least a portion of the unmasked version of the sensitive data with a mask, thereby generating a masked version of the sensitive data and concealing the at least a portion of the unmasked version of the sensitive data when content is displayed based on the code).
Regarding claim 3 the combination of Cohen and Page teaches all the limitations of claim 1 above, Cohen further teaches based on the at least one user input, generating a first alert via an analysis system; and causing to output the first alert via the first GUI (Cohen on [0188] teaches an execution environment 5-4-02 having alert API code 5-4-04, which triggers display of graphical element 5-4-08 (shown as an alert box), which may be displayed according to an underlying API and/or associated with input data. As shown in this exemplary figure, graphical element 5-4-08 is associated with a string representation of an origin of the API invocation 5-4-06 (“<script type=“text/javascript”>alert(“javascript inside script tag”); </script>”). See on [0216, 0290 and 0301] teaches the JavaScript agent instantiated inside the iframe may detect an input event (e.g., a key press or click) and determine a click-jacking attempt based on a user interaction with a hidden iframe. In response to the detection, the JavaScript agent may abort the input event and/or generate a suitable alert).
Regarding claim 4 the combination of Cohen and Page teaches all the limitations of claim 1 above, Cohen further teaches based on the at least one user input, generating a second alert via an analysis system; and causing to output the second alert via a second GUI (Cohen on [0188] teaches an execution environment 5-4-02 having alert API code 5-4-04, which triggers display of graphical element 5-4-08 (shown as an alert box), which may be displayed according to an underlying API and/or associated with input data. As shown in this exemplary figure, graphical element 5-4-08 is associated with a string representation of an origin of the API invocation 5-4-06 (“<script type=“text/javascript”>alert(“javascript inside script tag”); </script>”). See on [0216, 0290 and 0301] teaches the JavaScript agent instantiated inside the iframe may detect an input event (e.g., a key press or click) and determine a click-jacking attempt based on a user interaction with a hidden iframe. In response to the detection, the JavaScript agent may abort the input event and/or generate a suitable alert).
Regarding claim 5 the combination of Cohen and Page teaches all the limitations of claim 1 above, Cohen further teaches upon modifying the HTML associated with the first content element to remove the accessibility element, initiating at least one protective measure via an analysis system (Cohen on [0076-0077] teaches the DOM may interface between the JavaScript engine of the browser application and the webpage document allowing to dynamically add, change, and remove HTML elements and attributes, change CSS style definitions, react to event, and create new events. See on [0525-0527] teaches replacing the at least one encoded runtime parameter, wherein the at least one runtime parameter includes a Hypertext Markup Language (HTML) string. See on [0594] teaches replace in the DOM at least a portion of the unmasked version of the sensitive data with a mask, thereby generating a masked version of the sensitive data and concealing the at least a portion of the unmasked version of the sensitive data when content is displayed based on the code. See on [0384-0385] teaches Replacing in the DOM at least a portion of the unmasked version of the sensitive data with a mask may involve accessing a DOM for a code in a memory allocated for a browser application, locating a copy of sensitive data in the DOM (e.g., based on an indicator), writing a different value (e.g., corresponding to a mask) and/or deleting at least one byte of the unmasked version of the sensitive data in the DOM (e.g., using an API invocation), shuffling at least two bytes of an unmasked version of sensitive data in the DOM, and/or performing any other operation facilitating obfuscation or hiding a display of at least one byte of an unmasked version of sensitive data. Such a replacement may generate a masked version of the sensitive data (e.g., in a DOM). Generating (e.g., generate) may include producing or creating, such as by executing a function, program, or application (e.g., implemented by an agent). A masked version of sensitive data may refer to representation of sensitive data obfuscating and/or hiding enough information contained in the sensitive data, such that exposing the masked version of sensitive data to an unauthorized party may prevent the unauthorized party from using the information (e.g., thereby avoiding causing loss, harm, or a disadvantage, for instance, to an authorized party of the sensitive data)).
Regarding claim 6 the combination of Cohen and Page teaches all the limitations of claim 1 above, Cohen further teaches wherein determining the accessibility element is associated with a first DRM-protected content element further comprises scanning, via the application server, the HTML associated with the first content element to detect at least one of alternative text (“AltText”), accessibility text, semantic HTML, or a heading (Cohen on [0397] teaches upon intercepting a request for sensitive data, an agent may analyze and parse the request to determine an element associated with the requested sensitive data (i.e., accessibility element). For example, the request may be formulated as an API invocation referencing an element associated with sensitive data (i.e., operation can be performed with server [0084]). See on [0381] teaches Sensitive data associated with at least one element may refer to sensitive data that is configured at least in part by the at least one element (e.g., as an assignment of sensitive data to a data container, a setting to format sensitive data, and/or an invocation to access sensitive data), sensitive data for which the at least one element (e.g., in a code) is configured to enable the display of, or sensitive data that is influenced by the at least one element. See on [0594] teaches identify the sensitive data based on an indicator; access a Document Object Model (DOM) associated with the code; identify, in the DOM, an unmasked version of the sensitive data. See on [0597-0607] teaches wherein the sensitive data is associated with at least one element associated with the code, and wherein identifying in the DOM the unmasked version of the sensitive data includes identifying the at least one element in the DOM, wherein the at least one element includes a hypertext markup language (HTML) element. See on [0169] teaches HTML code to identify semantic HTML element. See on [0370] teaches a descriptive text such as using “alt”, a title, a path or URL, or any other string of characters associated with sensitive data).
Regarding claim 8 the combination of Cohen and Page teaches all the limitations of claim 1 above, Cohen further teaches detecting, via the application server, initiation of at least one HTML modification event, wherein the at least one HTML modification event includes at least one JavaScript event; and upon detecting initiation of the at least one HTML modification event, modifying the HTML associated with the first content element to remove the accessibility element via the application server (Cohen on [0076-0077] teaches the DOM may interface between the JavaScript engine of the browser application and the webpage document allowing to dynamically add, change, and remove HTML elements and attributes, change CSS style definitions, react to event, and create new events. See on [0525-0527] teaches replacing the at least one encoded runtime parameter, wherein the at least one runtime parameter includes a Hypertext Markup Language (HTML) string. See on [0594] teaches replace in the DOM at least a portion of the unmasked version of the sensitive data with a mask, thereby generating a masked version of the sensitive data and concealing the at least a portion of the unmasked version of the sensitive data when content is displayed based on the code. See on [0384-0385] teaches Replacing in the DOM at least a portion of the unmasked version of the sensitive data with a mask may involve accessing a DOM for a code in a memory allocated for a browser application, locating a copy of sensitive data in the DOM (e.g., based on an indicator), writing a different value (e.g., corresponding to a mask) and/or deleting at least one byte of the unmasked version of the sensitive data in the DOM (e.g., using an API invocation), shuffling at least two bytes of an unmasked version of sensitive data in the DOM, and/or performing any other operation facilitating obfuscation or hiding a display of at least one byte of an unmasked version of sensitive data. Such a replacement may generate a masked version of the sensitive data (e.g., in a DOM). Generating (e.g., generate) may include producing or creating, such as by executing a function, program, or application (e.g., implemented by an agent). A masked version of sensitive data may refer to representation of sensitive data obfuscating and/or hiding enough information contained in the sensitive data, such that exposing the masked version of sensitive data to an unauthorized party may prevent the unauthorized party from using the information (e.g., thereby avoiding causing loss, harm, or a disadvantage, for instance, to an authorized party of the sensitive data)).
Regarding claim 9 the combination of Cohen and Page teaches all the limitations of claim 8 above, Cohen further teaches wherein the at least one JavaScript event includes at least one of window focus, window blur, JavaScript editing pane activation, JavaScript editing pane deactivation, JavaScript editing pane width change, or JavaScript editing pane height change (Cohen on [0223 and 0237] teaches a size property may be defined for a height and/or width of a web element. A size property for a specific web element may be defined in a CSS code section for a webpage by referencing an identifier for the specific web element. Alternatively, a size property for a web element may be inherited from a parent element, set as an inline HTML instruction, or set inside a JavaScript procedure. For example, the size for a web element may be smaller than another, larger, web element such that superimposing the display of the smaller and larger web elements may cause the smaller element to be blocked by the larger web element. See on [0384] teaches mask may be implemented by substituting one or more characters (e.g., replacing a character with “*” or “#”), shuffling one or more characters (e.g., converting “string” to “gismt”), nullifying or deleting one or more characters, encrypting data, blurring and/or pixelating (e.g., image and/or video data), muting and/or garbling (e.g., audio data), redacting data, or implementing any other type of encoding to obfuscate and/or conceal information. Replacing may refer to substituting or removing an item and inserting a different item in its place).
Claims 10 and 21 are rejected under 35 U.S.C. 103 as being unpatentable over Cohen (US 20240403413) in view of Page et al (hereinafter Page) (US 20220121723) and further in view of Litty et al (hereinafter Litty) (US 11979383).
Regarding claim 10 the combination of Cohen and Page teaches all the limitations of claim 1 above, the combination fails to explicitly teach further comprising: detecting an end event, wherein the end event includes cessation of the at least one user input; upon detecting the end event, modifying the HTML associated with the modified first content element to insert the accessibility element to generate a modified second content element via the application server; and causing to output, via the first GUI, the modified second content element such that the accessibility element is caused to be output, however Litty from analogous art teaches
detecting an end event, wherein the end event includes cessation of the at least one user input; upon detecting the end event, modifying the HTML associated with the modified first content element to insert the accessibility element to generate a modified second content element via the application server; and causing to output, via the first GUI, the modified second content element such that the accessibility element is caused to be output (Litty on [col 27 line 55-67 and col 28 line 1-20] teaches If recording is not enabled, continue with normal page load and skip the following steps. If recording is enabled, begin capturing the data specified by policy; if user activity is detected, enable recording of expensive data items such as screenshots per the parameters outlined by policy (see example above). Optionally, screenshots can blur out sensitive form fields on the page in order to keep personal info such as credit card numbers and SSNs private. Blurring of designated fields may be accomplished in a variety of ways. One approach to performing this blurring action is to OCR the screen and apply DLP or other rules that identify the structure of such information. Another approach is to temporarily apply a CSS blur filter on the target elements (e.g., all <input> elements) prior to taking the screenshot, and then remove the blur effect afterward).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Litty into the combined teaching of Cohen and Page by removing the blur effect after the event with respect to user input ends. One would be motivated to do so in order to secure sensitive information for being exposed to unauthorized entity by blurring the sensitive information when screen recording is detected and removing the blur when screen recording is disabled (Litty col 27 line 55-67 and col 28 line 1-20).
Regarding claim 21 the combination of Cohen and Page teaches all the limitations of claim 2 above, the combination fails to explicitly teach wherein determining whether the digital extraction is indicated includes detecting (i) at least one indirect measure of digital extraction, (ii) at least one user input indicative of digital extraction, (iii) a simultaneous operation of a screensharing application and while receiving the at least one user input, or (iv) an inference or a prediction of digital extraction, however Litty from analogous art teaches
wherein determining whether the digital extraction is indicated includes detecting (i) at least one indirect measure of digital extraction, (ii) at least one user input indicative of digital extraction, (iii) a simultaneous operation of a screensharing application and while receiving the at least one user input, or (iv) an inference or a prediction of digital extraction (Litty on [col 27 lines 55-67 and col 28 lines 1-2] teaches If recording is not enabled, continue with normal page load and skip the following steps. If recording is enabled, begin capturing the data specified by policy; if user activity is detected, enable recording of expensive data items such as screenshots per the parameters outlined by policy (see example above). Optionally, screenshots can blur out sensitive form fields on the page in order to keep personal info such as credit card numbers and SSNs private. Blurring of designated fields may be accomplished in a variety of ways. One approach to performing this blurring action is to OCR the screen and apply DLP or other rules that identify the structure of such information. Another approach is to temporarily apply a CSS blur filter on the target elements (e.g., all <input> elements) prior to taking the screenshot, and then remove the blur effect afterward).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Litty into the teaching of Cohen by modifying the HTML to remove the sensitive data when screen recoding the browser. One would be motivated to do so in order to secure sensitive information for being exposed to unauthorized entity by blurring the sensitive information when screen recording is detected and removing the blur when screen recording is disabled (Litty col 27 line 55-67 and col 28 line 1-20).
Claim 11-16 and 18-19 is rejected under 35 U.S.C. 103 as being unpatentable over Cohen (US 20240403413) in view of Litty et al (hereinafter Litty) (US 11979383).
Regarding claim 11 Cohen teaches a system, the system comprising: (Cohen on [0016] teaches a system for masking sensitive data, thereby generating a masked version of the sensitive data and concealing the at least a portion of the unmasked version of the sensitive data when content is displayed);
at least one memory storing instructions (Cohen on [0056] teaches memory storing instructions);
and at least one processor operatively connected to the memory (Cohen on [0056] teaches memory storing instructions executed by a processor);
and configured to execute the instructions to perform operations for obfuscating an accessibility element using digital rights management (DRM) protection, the operations including: (Cohen on [0016] teaches a system for masking sensitive data, thereby generating a masked version of the sensitive data and concealing the at least a portion of the unmasked version of the sensitive data when content is displayed);
determining, via an application server, the accessibility element is associated with a first DRM-protected content element (Cohen on [0397] teaches upon intercepting a request for sensitive data, an agent may analyze and parse the request to determine an element associated with the requested sensitive data (i.e., accessibility element). For example, the request may be formulated as an API invocation referencing an element associated with sensitive data (i.e., operation can be performed with server [0084]). See on [0381] teaches Sensitive data associated with at least one element may refer to sensitive data that is configured at least in part by the at least one element (e.g., as an assignment of sensitive data to a data container, a setting to format sensitive data, and/or an invocation to access sensitive data), sensitive data for which the at least one element (e.g., in a code) is configured to enable the display of, or sensitive data that is influenced by the at least one element. See on [0594] teaches identify the sensitive data based on an indicator; access a Document Object Model (DOM) associated with the code; identify, in the DOM, an unmasked version of the sensitive data. See on [0597-0607] teaches wherein the sensitive data is associated with at least one element associated with the code, and wherein identifying in the DOM the unmasked version of the sensitive data includes identifying the at least one element in the DOM, wherein the at least one element includes a hypertext markup language (HTML) element);
obtaining, via the application server, at least one user input associated with the accessibility element or the first DRM-protected content element (Cohen on [0076-0079] teaches receiving via graphical user interface a click event from user associated with specific webpage element. See on [0381] teaches receiving via user interface input associated with sensitive data, the sensitive data is associated with at least one element associated with the code. An element associated with a code (e.g., a web element) may refer to a distinct section of code (e.g., HTML, CSS, and/or JavaScript code) associated with a webpage (e.g., corresponding to a section of a webpage). For instance, the at least one element may include a hypertext markup language (HTML) element. An HTML element may a portion of an HTML code delineated with at least one tag (e.g., “<” and “>”));
wherein the at least one user input includes at least one of hovering, selecting, or clicking, wherein the at least one user input has been obtained via a first graphical user interface ("GUI") of a first user device (Cohen on [0077] teaches events may include user interface actions (e.g., a mouse click or keyboard entry). See on [0104-0105 and 0119] teaches the user input may include at least one of: a computer mouse gesture, a gesture on a touch screen, a cursor movement, or a key press);
(Cohen on [0076-0077] teaches To render an HTML webpage within a browser application running on a computing device, the browser application may load the HTML source code into memory and parse the HTML code to extract the elements for displaying to a user in a manner conforming with the logical structure. To render dynamic content, which may be defined using JavaScript, after the webpage code is loaded, the browser application may create a DOM as an object-oriented representation of the HTML portion of the webpage code. The DOM may interface between the JavaScript engine of the browser application and the webpage document allowing to dynamically add, change, and remove HTML elements and attributes, change CSS style definitions, react to event, and create new events.. See on [0525-0527] teaches replacing the at least one encoded runtime parameter, wherein the at least one runtime parameter includes a Hypertext Markup Language (HTML) string. See on [0594] teaches replace in the DOM at least a portion of the unmasked version of the sensitive data with a mask, thereby generating a masked version of the sensitive data and concealing the at least a portion of the unmasked version of the sensitive data when content is displayed based on the code);
and causing to output, via the first GUI, the modified first DRM-protected content element such that the accessibility element is no longer caused to be output (Cohen on [0401-0402 and 0593-0595] teaches replace in the DOM at least a portion of the unmasked version of the sensitive data with a mask, thereby generating a masked version of the sensitive data and concealing the at least a portion of the unmasked version of the sensitive data when content is displayed based on the code and preventing display of the at least a portion of the unmasked version of the sensitive data. See on [0377 and 0394] teaches an agent 9-110 (e.g., corresponding to cybersecurity agent 226) may provide a virtual barrier between code 9-108 and DOM 9-106, preventing a display of sensitive data 9-104 included in code 9-108 without affecting integrity (e.g., maintaining integrity) of sensitive data 9-104 in code 9-108. Agent 9-110 may identify sensitive data 9-104 in code 9-108, for instance, by scanning code 9-108 (e.g., and/or a runtime version of code 9-108, such as DOM 9-106) to detect one or more contextual character sequences, such as a declaration for an HTML div element 9-112, including an identifier 9-114 (e.g., “credit card”) and sensitive data 9-104).
Although Cohen teaches modifying the HTML elemnts based on user inputs but fails to teach obtaining, via the application server, a determination whether digital extraction is indicated from a browser module, wherein determining whether the digital extraction is indicated includes detecting (i) at least one indirect measure of digital extraction, (ii) at least one user input indicative of digital extraction, (iii) a simultaneous operation of a screensharing application and while receiving the at least one user input, or (iv) an inference or a prediction of digital extraction, however Litty from analogous art teaches
obtaining, via the application server, a determination whether digital extraction is indicated from a browser module, wherein determining whether the digital extraction is indicated includes detecting (i) at least one indirect measure of digital extraction, (ii) at least one user input indicative of digital extraction, (iii) a simultaneous operation of a screensharing application and while receiving the at least one user input, or (iv) an inference or a prediction of digital extraction (Litty on [col 27 lines 55-67 and col 28 lines 1-2] teaches If recording is not enabled, continue with normal page load and skip the following steps. If recording is enabled, begin capturing the data specified by policy; if user activity is detected, enable recording of expensive data items such as screenshots per the parameters outlined by policy (see example above). Optionally, screenshots can blur out sensitive form fields on the page in order to keep personal info such as credit card numbers and SSNs private. Blurring of designated fields may be accomplished in a variety of ways. One approach to performing this blurring action is to OCR the screen and apply DLP or other rules that identify the structure of such information. Another approach is to temporarily apply a CSS blur filter on the target elements (e.g., all <input> elements) prior to taking the screenshot, and then remove the blur effect afterward);
upon obtaining the determination that the digital extraction is indicated and based on the at least one user input, modifying, via the application server, a HyperText Markup Language ("HTML" associated with the first DRM-protected content element to remove the accessibility element via the application server (Litty on [col 27 lines 55-67 and col 28 lines 1-2] teaches If recording is not enabled, continue with normal page load and skip the following steps. If recording is enabled, begin capturing the data specified by policy; if user activity is detected, enable recording of expensive data items such as screenshots per the parameters outlined by policy (see example above). Optionally, screenshots can blur out sensitive form fields on the page in order to keep personal info such as credit card numbers and SSNs private. Blurring of designated fields may be accomplished in a variety of ways. One approach to performing this blurring action is to OCR the screen and apply DLP or other rules that identify the structure of such information. Another approach is to temporarily apply a CSS blur filter on the target elements (e.g., all <input> elements) prior to taking the screenshot, and then remove the blur effect afterward).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Litty into the teaching of Cohen by modifying the HTML to remove the sensitive data when screen recoding the browser. One would be motivated to do so in order to secure sensitive information for being exposed to unauthorized entity by blurring the sensitive information when screen recording is detected and removing the blur when screen recording is disabled (Litty col 27 line 55-67 and col 28 line 1-20).
Regarding claim 12 the combination of Cohen and Litty teaches all the limitations of claim 11 above, Cohen further teaches obtaining, via the application server a determination whether digital extraction is indicated from a browser module and upon obtaining the determination that the digital extraction is indicated modifying the HTML associated with the first DRM- protected content element to remove the accessibility element via the application server (Cohen on [0076-0077] teaches the DOM may interface between the JavaScript engine of the browser application and the webpage document allowing to dynamically add, change, and remove HTML elements and attributes, change CSS style definitions, react to event, and create new events. See on [0525-0527] teaches replacing the at least one encoded runtime parameter, wherein the at least one runtime parameter includes a Hypertext Markup Language (HTML) string. See on [0594] teaches replace in the DOM at least a portion of the unmasked version of the sensitive data with a mask, thereby generating a masked version of the sensitive data and concealing the at least a portion of the unmasked version of the sensitive data when content is displayed based on the code).
Regarding claim 13 the combination of Cohen and Litty teaches all the limitations of claim 11 above, Cohen further teaches based on the at least one user input, generating a first alert via an analysis system; and causing to output the first alert via the first GUI (Cohen on [0188] teaches an execution environment 5-4-02 having alert API code 5-4-04, which triggers display of graphical element 5-4-08 (shown as an alert box), which may be displayed according to an underlying API and/or associated with input data. As shown in this exemplary figure, graphical element 5-4-08 is associated with a string representation of an origin of the API invocation 5-4-06 (“<script type=“text/javascript”>alert(“javascript inside script tag”); </script>”). See on [0216, 0290 and 0301] teaches the JavaScript agent instantiated inside the iframe may detect an input event (e.g., a key press or click) and determine a click-jacking attempt based on a user interaction with a hidden iframe. In response to the detection, the JavaScript agent may abort the input event and/or generate a suitable alert).
Regarding claim 14 the combination of Cohen and Litty teaches all the limitations of claim 11 above, Cohen further teaches based on the at least one user input, generating a second alert via an analysis system; and causing to output the second alert via a second GUI (Cohen on [0188] teaches an execution environment 5-4-02 having alert API code 5-4-04, which triggers display of graphical element 5-4-08 (shown as an alert box), which may be displayed according to an underlying API and/or associated with input data. As shown in this exemplary figure, graphical element 5-4-08 is associated with a string representation of an origin of the API invocation 5-4-06 (“<script type=“text/javascript”>alert(“javascript inside script tag”); </script>”). See on [0216, 0290 and 0301] teaches the JavaScript agent instantiated inside the iframe may detect an input event (e.g., a key press or click) and determine a click-jacking attempt based on a user interaction with a hidden iframe. In response to the detection, the JavaScript agent may abort the input event and/or generate a suitable alert).
Regarding claim 15 the combination of Cohen and Litty teaches all the limitations of claim 11 above, Cohen further teaches upon modifying the HTML associated with the first content element to remove the accessibility element, initiating at least one protective measure via an analysis system (Cohen on [0076-0077] teaches the DOM may interface between the JavaScript engine of the browser application and the webpage document allowing to dynamically add, change, and remove HTML elements and attributes, change CSS style definitions, react to event, and create new events. See on [0525-0527] teaches replacing the at least one encoded runtime parameter, wherein the at least one runtime parameter includes a Hypertext Markup Language (HTML) string. See on [0594] teaches replace in the DOM at least a portion of the unmasked version of the sensitive data with a mask, thereby generating a masked version of the sensitive data and concealing the at least a portion of the unmasked version of the sensitive data when content is displayed based on the code. See on [0384-0385] teaches Replacing in the DOM at least a portion of the unmasked version of the sensitive data with a mask may involve accessing a DOM for a code in a memory allocated for a browser application, locating a copy of sensitive data in the DOM (e.g., based on an indicator), writing a different value (e.g., corresponding to a mask) and/or deleting at least one byte of the unmasked version of the sensitive data in the DOM (e.g., using an API invocation), shuffling at least two bytes of an unmasked version of sensitive data in the DOM, and/or performing any other operation facilitating obfuscation or hiding a display of at least one byte of an unmasked version of sensitive data. Such a replacement may generate a masked version of the sensitive data (e.g., in a DOM). Generating (e.g., generate) may include producing or creating, such as by executing a function, program, or application (e.g., implemented by an agent). A masked version of sensitive data may refer to representation of sensitive data obfuscating and/or hiding enough information contained in the sensitive data, such that exposing the masked version of sensitive data to an unauthorized party may prevent the unauthorized party from using the information (e.g., thereby avoiding causing loss, harm, or a disadvantage, for instance, to an authorized party of the sensitive data)).
Regarding claim 16 the combination of Cohen and Litty teaches all the limitations of claim 11 above, Cohen further teaches wherein determining the accessibility element is associated with a first content element further comprises scanning, via the application server, the HTML associated with the first content element to detect at least one of alternative text (“AltText”), accessibility text, semantic HTML, or a heading (Cohen on [0397] teaches upon intercepting a request for sensitive data, an agent may analyze and parse the request to determine an element associated with the requested sensitive data (i.e., accessibility element). For example, the request may be formulated as an API invocation referencing an element associated with sensitive data (i.e., operation can be performed with server [0084]). See on [0381] teaches Sensitive data associated with at least one element may refer to sensitive data that is configured at least in part by the at least one element (e.g., as an assignment of sensitive data to a data container, a setting to format sensitive data, and/or an invocation to access sensitive data), sensitive data for which the at least one element (e.g., in a code) is configured to enable the display of, or sensitive data that is influenced by the at least one element. See on [0594] teaches identify the sensitive data based on an indicator; access a Document Object Model (DOM) associated with the code; identify, in the DOM, an unmasked version of the sensitive data. See on [0597-0607] teaches wherein the sensitive data is associated with at least one element associated with the code, and wherein identifying in the DOM the unmasked version of the sensitive data includes identifying the at least one element in the DOM, wherein the at least one element includes a hypertext markup language (HTML) element. See on [0169] teaches HTML code to identify semantic HTML element. See on [0370] teaches a descriptive text such as using “alt”, a title, a path or URL, or any other string of characters associated with sensitive data).
Regarding claim 18 the combination of Cohen and Litty teaches all the limitations of claim 11 above, Cohen further teaches detecting, via the application server, initiation of at least one HTML modification event, wherein the at least one HTML modification event includes at least one JavaScript event; and upon detecting initiation of the at least one HTML modification event, modifying the HTML associated with the first content element to remove the accessibility element via the application server (Cohen on [0076-0077] teaches the DOM may interface between the JavaScript engine of the browser application and the webpage document allowing to dynamically add, change, and remove HTML elements and attributes, change CSS style definitions, react to event, and create new events. See on [0525-0527] teaches replacing the at least one encoded runtime parameter, wherein the at least one runtime parameter includes a Hypertext Markup Language (HTML) string. See on [0594] teaches replace in the DOM at least a portion of the unmasked version of the sensitive data with a mask, thereby generating a masked version of the sensitive data and concealing the at least a portion of the unmasked version of the sensitive data when content is displayed based on the code. See on [0384-0385] teaches Replacing in the DOM at least a portion of the unmasked version of the sensitive data with a mask may involve accessing a DOM for a code in a memory allocated for a browser application, locating a copy of sensitive data in the DOM (e.g., based on an indicator), writing a different value (e.g., corresponding to a mask) and/or deleting at least one byte of the unmasked version of the sensitive data in the DOM (e.g., using an API invocation), shuffling at least two bytes of an unmasked version of sensitive data in the DOM, and/or performing any other operation facilitating obfuscation or hiding a display of at least one byte of an unmasked version of sensitive data. Such a replacement may generate a masked version of the sensitive data (e.g., in a DOM). Generating (e.g., generate) may include producing or creating, such as by executing a function, program, or application (e.g., implemented by an agent). A masked version of sensitive data may refer to representation of sensitive data obfuscating and/or hiding enough information contained in the sensitive data, such that exposing the masked version of sensitive data to an unauthorized party may prevent the unauthorized party from using the information (e.g., thereby avoiding causing loss, harm, or a disadvantage, for instance, to an authorized party of the sensitive data)).
Regarding claim 19 the combination of Cohen and Litty teaches all the limitations of claims 11 above, Litty further teaches detecting an end event, wherein the end event includes cessation of the at least one user input; upon detecting the end event, modifying the HTML associated with the modified first content element to insert the accessibility element to generate a modified second content element via the application server; and causing to output, via the first GUI, the modified second content element such that the accessibility element is caused to be output (Litty on [col 27 line 55-67 and col 28 line 1-20] teaches If recording is not enabled, continue with normal page load and skip the following steps. If recording is enabled, begin capturing the data specified by policy; if user activity is detected, enable recording of expensive data items such as screenshots per the parameters outlined by policy (see example above). Optionally, screenshots can blur out sensitive form fields on the page in order to keep personal info such as credit card numbers and SSNs private. Blurring of designated fields may be accomplished in a variety of ways. One approach to performing this blurring action is to OCR the screen and apply DLP or other rules that identify the structure of such information. Another approach is to temporarily apply a CSS blur filter on the target elements (e.g., all <input> elements) prior to taking the screenshot, and then remove the blur effect afterward).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Litty into the teaching of Cohen by removing the blur effect after the event with respect to user input ends. One would be motivated to do so in order to secure sensitive information for being exposed to unauthorized entity by blurring the sensitive information when screen recording is detected and removing the blur when screen recording is disabled (Litty col 27 line 55-67 and col 28 line 1-20).
Claims 17 and 20 is rejected under 35 U.S.C. 103 as being unpatentable over Cohen (US 20240403413) in view of Litty et al (hereinafter Litty) (US 11979383) and further in view of Page et al (hereinafter Page) (US 20220121723).
Regarding claim 17 the combination of Cohen and Litty teaches all the limitations of claim 11 above, the combination fails to explicitly teach wherein modifying the HTML associated with the first content element to remove the accessibility element includes removing an Accessible Rich Internet Applications (“ARIA”) from a Document Object Model (“DOM”) of the HTML, however Page from analogous art teaches
wherein modifying the HTML associated with the first content element to remove the accessibility element includes removing an Accessible Rich Internet Applications (“ARIA”) from a Document Object Model (“DOM”) of the HTML (Page on [0267-0268] teaches one or more attributes that provide accessible names to one or more elements may be removed such as, for example, aria-label and/or aria-labelledby attributes. In some embodiments, web developers often place ARIA attributes purposely, and removing attributes may decrease accessibility. Further teaches one or more ARIA attributes may be substituted or removed).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Page into the combined teaching of Cohen and Litty by removing an Accessible Rich Internet Applications (“ARIA”) from a Document Object Model. One would be motivated to do so in order to facilitate enhanced accessibility of website (Page [0008]).
Regarding claim 20 Cohen teaches a method for obfuscating an accessibility element using digital rights management (“DRM”) protections, the method comprising: (Cohen on [0016] teaches method for masking sensitive data, thereby generating a masked version of the sensitive data and concealing the at least a portion of the unmasked version of the sensitive data when content is displayed);
determining, via an application server, the accessibility element is associated with a first DRM-protected content element by scanning HyperText Markup Language (HTML) associated with the first DRM-protected content element to detect at least one of alternative text (“AltText”), accessibility text, semantic HTML, or a heading (Cohen on [0397] teaches upon intercepting a request for sensitive data, an agent may analyze and parse the request to determine an element associated with the requested sensitive data (i.e., accessibility element). For example, the request may be formulated as an API invocation referencing an element associated with sensitive data (i.e., operation can be performed with server [0084]). See on [0381] teaches Sensitive data associated with at least one element may refer to sensitive data that is configured at least in part by the at least one element (e.g., as an assignment of sensitive data to a data container, a setting to format sensitive data, and/or an invocation to access sensitive data), sensitive data for which the at least one element (e.g., in a code) is configured to enable the display of, or sensitive data that is influenced by the at least one element. See on [0594] teaches identify the sensitive data based on an indicator; access a Document Object Model (DOM) associated with the code; identify, in the DOM, an unmasked version of the sensitive data. See on [0597-0607] teaches wherein the sensitive data is associated with at least one element associated with the code, and wherein identifying in the DOM the unmasked version of the sensitive data includes identifying the at least one element in the DOM, wherein the at least one element includes a hypertext markup language (HTML) element. See on [0169] teaches HTML code to identify semantic HTML element. See on [0370] teaches a descriptive text such as using “alt”, a title, a path or URL, or any other string of characters associated with sensitive data);
detecting, via the application server, at least one of: (i) initiation of at least one HTML modification event, wherein the at least one HTML modification event includes at least one JavaScript event, wherein the at least one JavaScript event includes at least one of window focus, window blur, JavaScript editing pane activation, JavaScript editing pane deactivation, JavaScript editing pane width change, or JavaScript editing pane height change, or (ii) receipt, via a first graphical user interface (“GUI”), at least one user input associated with the accessibility element or the first content element (Cohen on [0076-0079] teaches receiving via graphical user interface a click event from user associated with specific webpage element. See on [0381] teaches receiving via user interface input associated with sensitive data, the sensitive data is associated with at least one element associated with the code. An element associated with a code (e.g., a web element) may refer to a distinct section of code (e.g., HTML, CSS, and/or JavaScript code) associated with a webpage (e.g., corresponding to a section of a webpage). For instance, the at least one element may include a hypertext markup language (HTML) element. An HTML element may a portion of an HTML code delineated with at least one tag (e.g., “<” and “>”));
wherein the at least one user input includes at least one of hovering, selecting, or clicking (Cohen on [0077] teaches events may include user interface actions (e.g., a mouse click or keyboard entry). See on [0104-0105 and 0119] teaches the user input may include at least one of: a computer mouse gesture, a gesture on a touch screen, a cursor movement, or a key press);
based on detecting the initiation of the at least one HTM modification event or the receipts of the at least one user input, modifying, via the application server, the HTML associated with the first DRM-protected content element to remove the accessibility element by removing (Cohen on [0076-0077] teaches the DOM may interface between the JavaScript engine of the browser application and the webpage document allowing to dynamically add, change, and remove HTML elements and attributes, change CSS style definitions, react to event, and create new events. See on [0525-0527] teaches replacing the at least one encoded runtime parameter, wherein the at least one runtime parameter includes a Hypertext Markup Language (HTML) string. See on [0594] teaches replace in the DOM at least a portion of the unmasked version of the sensitive data with a mask, thereby generating a masked version of the sensitive data and concealing the at least a portion of the unmasked version of the sensitive data when content is displayed based on the code);
causing to output, via the first GUI, the modified first DRM-protected content element such that the accessibility element is no longer caused to be output (Cohen on [0401-0402 and 0593-0595] teaches replace in the DOM at least a portion of the unmasked version of the sensitive data with a mask, thereby generating a masked version of the sensitive data and concealing the at least a portion of the unmasked version of the sensitive data when content is displayed based on the code and preventing display of the at least a portion of the unmasked version of the sensitive data. See on [0377 and 0394] teaches an agent 9-110 (e.g., corresponding to cybersecurity agent 226) may provide a virtual barrier between code 9-108 and DOM 9-106, preventing a display of sensitive data 9-104 included in code 9-108 without affecting integrity (e.g., maintaining integrity) of sensitive data 9-104 in code 9-108. Agent 9-110 may identify sensitive data 9-104 in code 9-108, for instance, by scanning code 9-108 (e.g., and/or a runtime version of code 9-108, such as DOM 9-106) to detect one or more contextual character sequences, such as a declaration for an HTML div element 9-112, including an identifier 9-114 (e.g., “credit card”) and sensitive data 9-104).
Cohen fails to explicitly teach detecting an end event, wherein the end event includes cessation of at least one of: (i) the at least one HTML modification event or (ii) the at least one user input; upon detecting the end event, modifying the HTML associated with the modified first content element to insert the accessibility element to generate a modified second content element via the application server; and causing to output, via the first GUI, the modified second content element such that the accessibility element is caused to be output, however Litty from analogous art teaches
detecting an end event, wherein the end event includes cessation of at least one of: (i) the at least one HTML modification event or (ii) the at least one user input; upon detecting the end event, modifying the HTML associated with the modified first DRM-protected content element to insert the accessibility element to generate a modified second content element via the application server; and causing to output, via the first GUI, the modified second DRM-protected content element such that the accessibility element is caused to be output (Litty on [col 27 line 55-67 and col 28 line 1-20] teaches If recording is not enabled, continue with normal page load and skip the following steps. If recording is enabled, begin capturing the data specified by policy; if user activity is detected, enable recording of expensive data items such as screenshots per the parameters outlined by policy (see example above). Optionally, screenshots can blur out sensitive form fields on the page in order to keep personal info such as credit card numbers and SSNs private. Blurring of designated fields may be accomplished in a variety of ways. One approach to performing this blurring action is to OCR the screen and apply DLP or other rules that identify the structure of such information. Another approach is to temporarily apply a CSS blur filter on the target elements (e.g., all <input> elements) prior to taking the screenshot, and then remove the blur effect afterward).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Litty into the teaching of Cohen by removing the blur effect after the event with respect to user input ends. One would be motivated to do so in order to secure sensitive information for being exposed to unauthorized entity by blurring the sensitive information when screen recording is detected and removing the blur when screen recording is disabled (Litty col 27 line 55-67 and col 28 line 1-20).
The combination fails to explicitly teach removing an ARIA from a DOM associated with the HTML, however Page from analogous art teaches
(Page on [0267-0268] teaches one or more attributes that provide accessible names to one or more elements may be removed such as, for example, aria-label and/or aria-labelledby attributes. In some embodiments, web developers often place ARIA attributes purposely, and removing attributes may decrease accessibility. Further teaches one or more ARIA attributes may be substituted or removed).
Thus, it would have been obvious to one ordinary skill in the art before the effective filing date to implement the teaching of Page into the combined teaching of Cohen and Litty by removing an Accessible Rich Internet Applications (“ARIA”) from a Document Object Model. One would be motivated to do so in order to facilitate enhanced accessibility of website (Page [0008]).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MOEEN KHAN whose telephone number is (571)272-3522. The examiner can normally be reached 7AM-5PM EST M-TH Alternate Fridays.
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, Shewaye Gelagay can be reached at (571)272-4219. 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.
/MOEEN KHAN/ Primary Examiner, Art Unit 2436
Prosecution Insights