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 .
Specification
The specification filed on October 03, 2024 is accepted.
Drawings
The drawings filed on October 03, 2024 are accepted.
Claim Objections
Claim 20 objected to because of the following informalities:
Claim 20 recites “a HTML” should read as “a HyperText Markup Language (“HTML”)”
Claim 20 recites “ARIA” should “an Accessible Rich Internet Applications (“ARIA”)”
Claim 20 recites “DOM” should read as “Document Object Model (“DOM”)”. Appropriate correction is required.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-6, 8, 9 and 11-18 is/are rejected under 35 U.S.C. 102 (a)(2) as being anticipated by Cohen (US 20240403413).
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 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);
receiving, 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);
modifying, via the application server, a HyperText Markup Language (“HTML”) associated with the first 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);
and causing to output, via the first GUI, the modified first 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).
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 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 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);
receiving, 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);
modifying, via the application server, a HyperText Markup Language (“HTML”) associated with the first 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);
and causing to output, via the first GUI, the modified first 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).
Regarding claim 2 and 12 Cohen teaches all the limitations of claims 1 and 11 respectively, Cohen further teaches further comprising: determining, via a browser module, whether digital extraction is indicated; and upon determining digital extraction is indicated and based on the at least one user input, 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).
Regarding claim 3 and 13 Cohen teaches all the limitations of claims 1 and 11 respectively, Cohen further teaches further comprising: 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 and 14 Cohen teaches all the limitations of claims 1 and 11 respectively, Cohen further teaches further comprising: 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 and 15 Cohen teaches all the limitations of claims 1 and 11 respectively, Cohen further teaches further comprising: 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 and 16 Cohen teaches all the limitations of claims 1 and 11 respectively, 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 8 and 18 Cohen teaches all the limitations of claims 1 and 11 respectively, Cohen further teaches further comprising: 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 Cohen 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).
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 7 and 17 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 7 and 17 Cohen teaches all the limitations of claims 1 and 11 respectively, Cohen 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 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]).
Claims 10 and 19 are 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 10 and 19 Cohen teaches all the limitations of claims 1 and 11 respectively, Cohen 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 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).
Claim 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 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 content element by scanning a 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);
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);
modifying, via the application server, the HTML associated with the first 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 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 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).
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
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Kumar et al (US 200250077693) is directed towards system for using narrow artificial intelligence (“AI”) to detect and secure confidential data. The methods may include using a camera on a user computer to capture a live camera feed of an area adjacent to the user computer. Methods may include identifying one or more unverified data elements in the captured data. In response to determining an unverified data element, methods may include securing the user computer. Methods may include capturing a screenshot of the user computer screen. Methods may include transmitting data extracted from the screenshot through an object identification algorithm. Methods may include identifying confidential data within the screenshot using a pattern analysis model. Methods may include recreating the screenshot using a narrow AI model. Methods may include blurring the confidential data in the recreated screenshot. Methods may include overwriting the screenshot to display the recreated screenshot on the user computer.
Remington et al (US 20200250323) is directed towards systems for preventing theft of sensitive information during a remote application session.
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