DETAILED ACTION
This Office action is in response to a Continuation application filed by Applicant on 11/6/2024.
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 .
Claim Objections
Claim 1 objected to because of the following informalities: Claim 1 recites, “…redacting to redact…”, which is unclear. Appropriate correction is required.
Double Patenting
The non-statutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A non-statutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 1-17 are rejected on the ground of non-statutory anticipation-type double patenting as being unpatentable over claims 1–18, of U.S. Patent No. 12,141,307 B2 (granted from Application No. 17/737,363).
Claim Rejections - 35 USC § 101
The present application, as claimed, satisfies the requirements for patent-eligible subject matter under 35 U.S.C. 101.
Claim Rejections - 35 USC § 102
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1–3, 8–11, 13–16 rejected under 35 U.S.C. 102(a)(1) as being anticipated by Coleman (US 2012/0036452 A1, published Feb. 9, 2012).
Regarding claim 1, Coleman discloses: a method of enabling sensitive information to be masked while screensharing HTML elements (dynamically determining components of a displayed webpage to be masked during a screensharing session. Coleman ¶ 33.), comprising the steps of: loading masking script to a browser (the source code can be included in one or more tags that are inserted within the web page, where the one or more tags can automatically load the source code. Once loaded, the source code can dynamically identify components and dynamically modify the web page. Coleman ¶ 35.), the browser having a DOM containing a set of HTML elements, a display of the browser forming a portion of visual content of an application display (the source code can analyze a document object model ("DOM") of the web page and determine whether each component of the web page is an element that should be displayed during a screen sharing session, or whether the component is an element that should be masked during the screen sharing session. Coleman ¶ 33.); loading a list of CSS selectors identifying a subset of the HTML elements to be masked; determining, by the masking script, locations and sizes of the subset of the HTML elements identified by the list of CSS selectors within the display of the browser (the source code can dynamically modify the style sheet (used to define a visual layout (such as borders and colors of borders of layout)) of the web page, which can comprise an external style sheet file that utilizes a style sheet language, such as Cascading Style Sheets ("CSS"), to identify components to be displayed during a screen sharing session with a visible indication, and to identify components to be masked during the screen sharing session with a masking indication. Coleman ¶ 34.); communicating a list of the locations and sizes of the subset of the HTML elements from the masking script to a screenshare client (multimedia format for transmitting the “masking indication” to the client, since the actual masking can be performed on the coupled computer’s shared screen. Coleman ¶ 73. Masking indications, include a corner location and determination of a border (horizontal and vertical distances for the color change) for the region to be masked. Coleman ¶¶ 67, 70 and 73); and redacting to redact corresponding regions of the application display by the screenshare client, when transmitting screensharing data on a screensharing session (a screen sharing session can be provided utilizing two screens where specific components of an application may be masked and thus, hidden from view. Coleman ¶ 74.).
Regarding claim 2, Coleman discloses the limitations of claim 1, wherein the locations and sizes of the HTML elements are each specified using two respective (x,y) coordinate values identifying opposite corners of a rectangular area encompassing the respective HTML element within coordinate space of the display of the browser (masking indications, which are a corner location and determination of a border (horizontal and vertical distances for the color change) for the region to be masked. Coleman ¶¶ 67, 70 and 73. Locating the visible corners. Coleman ¶ 63.).
Regarding claim 3, Coleman discloses the limitations of claim 2, wherein the coordinate values are implemented as (x,y) offset values specifying locations relative to edge of the display of the browser (the screen capture module searches and locates the visible corner of masking border 625, traces masking border 625 in horizontal and vertical directions extending from the visible corner, inserts the missing corners, and inserts the missing masking border extending from the inserted corners to complete masking border 625, where the inserted corners and inserted masking border are indicated by the dashed lines of masking border 625 in FIG. 6. Coleman ¶ 61.).
Regarding claim 8, Coleman discloses the limitations of claim 1, further comprising: capturing, by the screensharing client on the screensharing session, screenshare data describing visible content displayed on the application display, at least a portion of the visible content being generated by the browser (the screen capture module uses source code in a scripting language for dynamic identification of components of the application and determines components to be displayed during the screen sharing session. Coleman ¶¶ 32–33.); receiving, by the screensharing client, the list of locations and sizes of redacted regions within the browser to be masked on the screensharing session; correlating the list of locations and sizes within the browser to redacted regions of the application display (dynamic identification of components of the application and determines components to be displayed or masked during the screen sharing session. Coleman ¶ 33. Masking indications are determined, which are a corner location and determination of a border (horizontal and vertical distances for the color change) for the region to be masked. Coleman ¶¶ 67, 70 and 73.); omitting content of the redacted regions, by the screensharing client from the screenshare data, to create redacted screenshare data, the redacted screenshare data describing visible content displayed on the application display outside of the redacted regions of the application display and not describing visible content displayed on the application display inside the redacted regions; and transmitting the redacted screenshare data on the screensharing session (the masking is performed at the computer operatively coupled to the first screen, and the masking is performed before the capturing and the transmitting are performed. Coleman ¶ 73.).
Regarding claim 9, Coleman discloses the limitations of claim 8, wherein correlating the list of locations and sizes to regions of the application display comprises determining a location of the browser within the application display (the screen capture module searches and locates the visible corner of masking border 625, traces masking border 625 in horizontal and vertical directions extending from the visible corner, inserts the missing corners, and inserts the missing masking border extending from the inserted corners to complete masking border 625, where the inserted corners and inserted masking border are indicated by the dashed lines of masking border 625 in FIG. 6. Coleman ¶ 61.).
Regarding claim 10, Coleman discloses the limitations of claim 8, wherein omitting content of the redacted regions comprises capturing screenshare data describing the visible content of the application display, and removing content of the redacted regions from the captured screenshare data (dynamic identification of components of the application and determines components to be displayed or masked during the screen sharing session. Coleman ¶ 33.).
Regarding claim 11, Coleman discloses the limitations of claim 8, wherein omitting content of the redacted regions comprises determining the locations of the redacted regions, and capturing screenshare data describing the visible content of the application display outside of the redacted regions while not capturing screenshare data describing the visible content of the application display inside the redacted regions (the screen capture module searches and locates the visible corner of masking border 625, traces masking border 625 in horizontal and vertical directions extending from the visible corner, inserts the missing corners, and inserts the missing masking border extending from the inserted corners to complete masking border 625, where the inserted corners and inserted masking border are indicated by the dashed lines of masking border 625 in FIG. 6. Coleman ¶ 61.).
Regarding claim 13, Coleman discloses: a method of enabling sensitive information to be masked while screensharing HTML elements (dynamically determining components of a displayed webpage to be masked during a screensharing session. Coleman ¶ 33.) comprising the steps of: capturing, by a screensharing client on a screensharing session, screenshare data describing visible content displayed on an application display, at least a portion of the visible content being generated by an browser (the screen capture module uses source code in a scripting language for dynamic identification of components of the application and determines components to be displayed during the screen sharing session. Coleman ¶¶ 32–33.); receiving, by a screensharing client, a list of redacted regions within the browser to be masked on the screensharing session, the list of redacted regions identifying locations of the redacted regions within the browser using a coordinate system associated with the browser (dynamic identification of components of the application and determines components to be displayed or masked during the screen sharing session. Coleman ¶ 33. Masking indications are determined, which are a corner location and determination of a border (horizontal and vertical distances for the color change) for the region to be masked. Coleman ¶¶ 67, 70 and 73.); correlating the list of locations and sizes within the browser to redacted regions of the application display (dynamic identification of components of the application and determines components to be displayed or masked during the screen sharing session. Coleman ¶ 33. Masking indications are determined, which are a corner location and determination of a border (horizontal and vertical distances for the color change) for the region to be masked. Coleman ¶¶ 67, 70 and 73.); omitting content of the redacted regions by the screensharing client from the screenshare data to create redacted screenshare data, the redacted screenshare data describing visible content displayed on the application display with the exception of the redacted regions of the application display; and transmitting the redacted screenshare data on the screensharing session (the masking is performed at the computer operatively coupled to the first screen, and the masking is performed before the capturing and the transmitting are performed. Coleman ¶ 73.).
Regarding claim 14, Coleman discloses the limitations of claim 13, wherein correlating the list of locations and sizes to regions of the application display comprises determining a location of the browser within the application display, and combining the location of the browser within the application display with the locations of the redacted regions within the browser (the screen capture module searches and locates the visible corner of masking border 625, traces masking border 625 in horizontal and vertical directions extending from the visible corner, inserts the missing corners, and inserts the missing masking border extending from the inserted corners to complete masking border 625, where the inserted corners and inserted masking border are indicated by the dashed lines of masking border 625 in FIG. 6. Coleman ¶ 61.).
Regarding claim 15, Coleman discloses the limitations of claim 13, wherein omitting content of the redacted regions comprises capturing screenshare data describing the visible content of the application display, and removing content of the redacted regions from the captured screenshare data (dynamic identification of components of the application and determines components to be displayed or masked during the screen sharing session. Coleman ¶ 33.).
Regarding claim 16, Coleman discloses the limitations of claim 13, wherein omitting content of the redacted regions comprises determining the locations of the redacted regions, and capturing screenshare data describing the visible content of the application display outside of the redacted regions while not capturing screenshare data describing the visible content of the application display inside the redacted regions (the screen capture module searches and locates the visible corner of masking border 625, traces masking border 625 in horizontal and vertical directions extending from the visible corner, inserts the missing corners, and inserts the missing masking border extending from the inserted corners to complete masking border 625, where the inserted corners and inserted masking border are indicated by the dashed lines of masking border 625 in FIG. 6. Coleman ¶ 61.).
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.
Claim 4 rejected under 35 U.S.C. 103 as being unpatentable over Coleman in view of Powell (US 2012/0173966 A1, published Jul. 5, 2012).
Regarding claim 4, Coleman discloses the limitations of claim 1. Coleman does not disclose: adding a mutation observer to the DOM to detect changes to the DOM.
However, Powell does disclose: adding a mutation observer to the DOM to detect changes to the DOM (the capture agent detects a DOM change within a webpage, including replacement of a DOM item. Powell ¶ 48.).
Therefore, it would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to modify the masking of components of displayed information in a browser during a screen sharing session of Coleman with the detection of changes to the DOM based upon the teachings of Powell. The motivation being detect user interaction with the website for example when a user selects an item displayed on the page for purposes of purchasing that item. Powell ¶ 46.
Claim 6 rejected under 35 U.S.C. 103 as being unpatentable over Coleman in view of Zhang (US 10,289,296 B1, issued May 14, 2019).
Regarding claim 6, Coleman discloses the limitations of claim 1. Coleman does not disclose: adding a scroll event handler to the DOM to detect scroll operations in the browser.
However, Zhang does disclose: adding a scroll event handler to the DOM to detect scroll operations in the browser (identifying items appended to the DOM including detecting a scroll action. Zhang 14:45–15:8.).
Therefore, it would have been prima facie obvious to one of ordinary skill in the art prior to the effective filing date of the claimed invention to modify the masking of components of displayed information in a browser during a screen sharing session of Coleman with detecting scroll operations by the user in the browser based upon the teachings of Zhang. The motivation being to automatically append content to a user browser display as the existing content is scrolled. Zhang ¶ 1:27–48.
Allowable Subject Matter
Claims 5, 7, 12, 17 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VANCE M LITTLE whose telephone number is (571) 270-0408. The examiner can normally be reached on Monday - Friday 9:30am - 5:30pm.
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, Jung (Jay) Kim can be reached on (571) 272-3804. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/VANCE M LITTLE/Primary Examiner, Art Unit 2493