DETAILED ACTION
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 .
Priority
Applicant’s claim to priority to the following provisional applications has been acknowledged by the examiner: 63/587,891; 63/665485; 63/683,063.
Claim Objections
Claims 1, 11, and 20 are objected to because of the following informalities: they recite “wherein the license include a decryption key and at least one rule,” which appears to have a typographical error concerning “include.” It is believed that the claim language should recite “includes.” Appropriate correction is required.
Claims 10 and 19 are objected to because of the following informalities: they recite “wherein the user interface include one or more of the second alert,” which appears to have a typographical error concerning “include.” It is believed that the claim language should recite “includes.” Appropriate correction is required.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-2 and 11-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Brockmann (US 2017/0005790 A1) in view of Shank (US 2022/0358234 A1).
Regarding claim 1, Brockmann discloses: A method for decrypting a HyperText Markup Language (HTML) (e.g., [0042]-[0045] of Brockmann concerning HTML5 DRM), the method comprising:
obtaining, via a browser module (e.g., browser 209 and player application 210 in FIG. 2A-B of Brockmann) associated with a first user device (client device in Brockmann), an encrypted [secure content];
Refer to at least [0054] and [0056] of Brockmann with respect to a user of the client launching secure content and the player application obtaining the secure content; the secure content being encrypted.
generating, via the browser module associated with the first user device, a first request to decrypt the encrypted [secure content];
Refer to at least [0054] and [0056] of Brockmann with respect to the player application requesting decryption of the secure content.
transmitting, via a processor (interpreted in view of [0044] of the instant specification), the first request and session data;
Refer to at least [0054]-[0055] of Brockmann with respect to obtaining user account information and client device identification information for the requested secure content.
obtaining, via the processor, a license for the encrypted [secure content], wherein the license include a decryption key and at least one rule;
Refer to at least [0054]-[0055] of Brockmann with respect to querying a license server and obtaining a license and policies (business rules). The license includes a wrapped content key.
determining, via the processor, whether the encrypted [secure content] satisfies the at least one rule of the license;
Refer to at least [0055], [0061]-[0062], [0065], and [0114] of Brockmann with respect to associated policies, such as possible output paths, play once, and only play within a specified period. Policy enforcement and validation determines whether the secure content can be decrypted.
upon determining the encrypted [secure content] satisfies the at least one rule of the license, decrypting, via the processor, the encrypted [secure content] using the decryption key; and
Refer to at least [0031] and [0056]-[0057] of Brockmann with respect to decrypting the secure content in adherence with the policy.
causing to output, via a graphical user interface (GUI) associated with the first user device, the decrypted [secure content].
Refer to at least [0057] of Brockmann with respect to the decrypted secure content being played back on a display device.
Although Brockmann concerns HTML5 DRM for secure content, Brockmann does not specify: the secure content further comprising an HTML element. However, Brockmann in view of Shank discloses: the secure content further comprising an HTML element.
Refer to at least the abstract, [0020], and [0043]-[0044] of Shank with respect to generally redacting HTML elements to mask sensitive information.
The teachings of Brockmann and Shank both concern access control for sensitive information, as well as HTML and streaming media sessions. As such, they are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Brockmann to further implement encrypting HTML elements associated with sensitive data because design incentives or market forces provided a reason to make an adaptation, and the invention resulted from application of the prior knowledge in a predictable manner (i.e., to allow for securely sharing media without leaking sensitive information as in [0018] and [0020] of Shank).
Regarding claim 2, Brockmann-Shank discloses: The method of claim 1, wherein the session data includes hardware data associated with the first user device.
Refer to at least [0054] of Brockmann with respect to a device identity such as a unique serial number.
Regarding independent claim 11, it is substantially similar to independent claim 1 above, and is therefore rejected for the same reasons (i.e., citations and obviousness rationale).
Regarding claim 12, it is substantially similar to claim 2 above, and is therefore likewise rejected.
Claim(s) 3-4, 13, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Brockmann-Shank as applied to claims 1-2 and 11-12 above, and further in view of Hassan (US 2018/0121663 A1).
Regarding claim 3, Brockmann-Shank discloses: The method of claim 1, further comprising: tagging the HTML element; and encrypting, via the processor, the tagged HTML element based on and the session data to generate the encrypted HTML element.
Refer to at least 190 in FIG.2, [0021], [0023], and [0043]-[0044] of Shank with respect to using CSS selectors to identify HTML elements that contain sensitive information for masking.
Refer to at least the abstract and [0041]-[0045] of Brockmann with respect to encryption for securing HTML content.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Brockmann-Shank to further implement CSS selectors to identify HTML elements for encryption because the particular known technique was recognized as part of the ordinary capabilities of one skilled in the art (i.e., CSS selectors for finding particular elements).
Brockmann-Shank does not specify: the encrypting further being based on the at least one rule. However, Brockmann-Shank in view of Hassan discloses: the encrypting further being based on the at least one rule.
Refer to at least the abstract and [0033]-[0035] of Hassan with respect to sharing policies determining which regions are to be encrypted during content sharing.
The teachings of Hassan likewise concern masking sensitive information and regions during content sharing (e.g., screen sharing), and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Brockmann-Shank to further implement encryption based on sharing policies for at least the purpose of more granular access control (e.g., according to user groups and particular allowed applications as in the cited portions of Hassan).
Regarding claim 4, it is rejected for substantially the same reasons as claim 3 above (i.e., the citations and obviousness rationale; CSS selectors).
Regarding claim 13, it is substantially similar to claim 3 above, and is therefore likewise rejected.
Regarding independent claim 20, it is substantially similar to independent claim 1 above, but further recites “tagging the HTML element; encrypting, via a processor, the tagged HTML element based on at least one rule and session data, wherein the session data includes hardware data associated with a first user device.” As such, claim 20 recites elements of claims 1-3 above, and is therefore rejected for the same reasons as claims 1-3 (i.e., the citations and obviousness rationale).
Claim(s) 5-7 and 14-16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Brockmann-Shank as applied to claims 1-2 and 11-12 above, and further in view of Baker (US 2022/0278992 A1).
Regarding claim 5, Brockmann-Shank discloses policy verification, but does not fully specify: upon determining the encrypted HTML element does not satisfy the at least one rule of the license, generating a first alert to first user; and causing to output, via the GUI associated with the first user device, the first alert. However, Brockmann-Shank in view of Baker discloses: upon determining the encrypted HTML element does not satisfy the at least one rule of the license, generating a first alert to first user; and causing to output, via the GUI associated with the first user device, the first alert.
Refer to at least [0086], [0091], [0094], and [0096] of Baker with respect to policy checks associated with sharing HTML5 content.
Refer to at least [0016] and [0088] of Baker with respect to a dialog presented to users based on the policy checks.
The teachings of Baker likewise concern protecting content during content sharing (e.g., screen sharing), and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Brockmann-Shank to further implement the policy checks and notifications of Baker (e.g., having the correct viewer application; being associated with the correct users) for at least the purpose of preventing accidental instances of insecure sharing (e.g., using an insecure viewer; choosing to share elements that should not be seen by certain participants).
Regarding claim 6, it is rejected for substantially the same reasons as claim 5 above (e.g., 325 in FIG. 3A and [0094]-[0096] of Baker).
Regarding claim 7, Brockmann-Shank-Baker discloses: The method of claim 1, further comprising: obtaining a second request from a second user associated with a second user device to decrypt the encrypted HTML element (e.g., [0100] of Baker); obtaining permission from a first user associated with the first user device to decrypt the encrypted HTML element based on the second request; and upon obtaining permission from the first user, detecting the encrypted HTML element.
Refer to at least [0016] of Baker, which discusses “presenting a dialog in connection with the local preview on the first browser, and only incorporating the HTML objects of the document into the DOM describing the content of the first browser and prior to forwarding the HTML objects as part of DOM from the first browser to the second browser on the co-browse session if inclusion of the HTML objects into the DOM is authorized via the dialog. In some embodiments, the method also includes deleting the HTML objects of the document and not incorporating the HTML objects of the document into the DOM if not authorized via the dialog.”
This claim would have been obvious for substantially the same reasons as claim 5 above.
Regarding claims 14-16, they are substantially similar to claims 5-7 above, and are therefore likewise rejected.
Claim(s) 8-10 and 17-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Brockmann-Shank-Baker as applied to claims 5-7 and 14-16 above, and further in view of Seo (US 2014/0240440 A1).
Regarding claim 8, Brockmann-Shank-Baker discloses: The method of claim 7, further comprising: upon determining the encrypted HTML element does not satisfy the at least one rule of the license, generating [an alert]:
Refer to at least [0086] and [0094]-[0096] of Baker with respect to evaluating content to be shared against policy and providing notification of failure.
Brockmann-Shank-Baker does not fully specify: generating a second alert to the second user; and causing to output, via a GUI associated with the second user device, the second alert. However, Brockmann-Shanks-Baker in view of Seo discloses: generating a second alert to the second user; and causing to output, via a GUI associated with the second user device, the second alert.
Refer to at least FIG. 11 and [0243]-[0245] of Seo with respect to a screen sharing refusal popup window in response to a screen sharing request.
The teachings of Seo likewise concern screen sharing, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Brockmann-Shank-Baker to further implement a refusal popup window because particular known technique was recognized as part of the ordinary capabilities of one skilled in the art, and for the purpose of letting requestors know the result of their request.
Regarding claim 9, it is rejected for substantially the same reasons as claim 8 above (i.e., the citations and obviousness rationale).
Regarding claim 10, Brockmann-Shank-Baker-Seo discloses: The method of claim 8, further comprising: upon determining the encrypted HTML element does not satisfy the at least one rule of the license, generating a user interface, wherein the user interface include one or more of the second alert, a blank screen, or a watermark; and causing to output, via the GUI associated with the first user device, the user interface.
Refer to at least 320 in FIG. 3A, 1445 in FIG. 14, and [0096] of Baker with respect to the case where the content is not shared.
This claim would have been obvious for substantially the same reasons as claim 5 above.
Regarding claims 17-19, they are substantially similar to claims 8-10 above, and are therefore likewise rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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, Jeffrey L Nickerson can be reached at (469) 295-9235. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of 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.
/V.S/Examiner, Art Unit 2432
/SYED A ZAIDI/Primary Examiner, Art Unit 2432