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
The following is a final office action in response to communications received January 30, 2026. Claims 1, 3, 6,13 and 20 have been amended. Therefore, claims 1-20 are pending and addressed below.
Response to Arguments
Applicant’s arguments filed January 30, 2026 is persuasive and the 35 USC 112(b) rejection is withdrawn.
Applicant’s arguments with respect to the rejections of amended claims 1, 13 and 20 under 35 U.S.C 102(a)(1) have been fully considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. A new ground of rejection under 35 U.S.C 103 is made in view of the combination of prior art of Kolam et al (US PG-PUB No. 20150143223 A1) and Demsey et al (US Patent No. 10642980 B1). (see below rejection details)
Therefore, claims 1, 13 and 20 are rejected under 35 U.S.C 103. As claims 2-12 are dependent directly or indirectly on claim 1, claims 14-19 are dependent directly or indirectly on claim 13, applicant’s argument with respect to the rejections of claim 2-12, 14-19 are moot.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 10-13, 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Kolam et al (US PG-PUB No. 20150143223 A1) in view of Demsey et al (US Patent No. 10642980 B1).
Regarding claims 1, 13 and 20, Kolam teaches a method, a system and a non-transitory tangible computer-readable storage device, the method for detecting restricted cross-origin requests by a webpage, comprising:
receiving, by a processor, webpage data associated with the webpage; determining, by the processor, a presence of cross-origin uniform resource locator (URL) data from the webpage data (Paragraph [0017]: “web browser 102 receives the content corresponding to the webpage (receiving webpage data associated with the webpage) through a network 106. Web browser 102 may run on different types of devices (receiving and determining by a processor of a device), including laptop computers, desktop computers, tablet computers, smartphones, and other mobile devices.”; Paragraph [0023]: “The various domains associated with the referenced dependent resources of a webpage can be determined by parsing the webpage. For example, with reference to FIG. 2, the image file and the video file are indicated on the webpage as being stored in different locations, each specified by a URL. As each URL includes its domain information, the domains of the image and video files can be determined by parsing their respective URLs (determining a presence of cross-origin URL data from the webpage data).”);
in response to cross-origin URL data being present, generating, by the processor, an independent request for a resource directly to a server associated with the cross-origin URL; determining, by the processor, whether the resource was restricted by the server (Paragraph [0024]: “CORS (Cross-Origin Resource Sharing) is a mechanism that allows one website to access another website's resources despite being under different domain names. CORS is an HTML5 feature and defines a way in which a web browser and the website server can interact to determine whether or not to allow the cross-origin request (determining whether the resource was restricted by the server). In the example shown in FIG. 3, web browser 102 makes same-origin request to domain 1 for resources but web browser 102 must make cross-domain requests to domain 2, domain 3 and domain 4 for resources (in response to cross-origin URL data being present, generating an independent request for a resource directly to a server associated with the cross-origin URL).”); and
Kolam fails to explicitly teach the independent request was generated from a privileged security context that operates at a higher permission level.
However, Demsey teaches generating, by the processor, operating in a privileged security context, an independent request for a resource directly to a server associated with the cross-origin URL from the privileged security context ([Col 9, Line 45]: “Now, at 230 the malicious code 155 existing in a third party internet malicious creative 154 is detected by the executing protection code 182 executed at 210, such as, for detecting cross-origin malicious code. Detecting at 230 may include protection code 182 intercepting and monitoring execution or rendering of malicious creative 154 and/or code 155. Detecting at 230 may include protection code 182 detecting and intercepting execution or activation of code 155 (protection code 182 is computer software that is operated in a privileged security context which intercepts execution when cross-origin malicious code is detected).”)).
Kolam is not relying on teaching, but Demsey teaches selectively generating, by the processor, mitigation data to mitigate presentation of the restricted resource associated with the cross-origin URL data ([Col 6, Line 39]: “FIG. 1B also shows protection code 182 having or executing browser sandbox 186 which may be a protected part, subpart (e.g. a plugin or extension) or version of a browser 114 executing malicious creative 154 with code 155. The sandbox 186 may be used by the protection code 182 to detect and/or intercept cross-origin malicious code 155, such as deferred types of unwanted action requested by the malicious code 155. The code 155 may have cross-origin malicious code 162 such as for causing cross-origin type unwanted actions and errors of code 155.”).
Kolam and Demsey are both considered to be analogous to the claimed invention because they both teach cross-origin resource sharing validation. Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have 1) modified the independent request generated by the processor disclosed by Kolam with adding operating in a privileged security context; 2) modified the processor with adding generating mitigation data to mitigate presentation of the restricted resource associated with the cross-origin URL, disclosed by Demsey.
One of the ordinary skills in the art would have been motivated to make this modification in order to intercept the cross-origin unwanted action, as suggested by Demsey in [Col 10, Line 1].
Regarding claim 10, Kolam and Demsey teaches all the features with respect to claim 1, as outlined above.
Demsey further teaches wherein the mitigation data includes notification that notifies a user of the restricted resource ([Col 15, Line 47]: “The sandbox 184 will then wrap the potential unwanted action code (wraps written scripts of malicious creative 154 in a java script (JS) closure which creates stripped creative 185 and overrides those scripts of the ad so that they do trigger an error) and listen to that code generate errors when a failed unwanted action attempt occurs (mitigation data includes notification) and/or listen to that code access fake location objects inside of the wrapper to know if the creative 185 includes malicious code (e.g., if the unwanted action code is bad or not). Listening can be performed by using intercepting writes to certain objects and “proxying” them through executing code 182. Of the code 182 notices someone (e.g., an unwanted action or other action of malicious creative 154) (notifies a user of the restricted resource) modifying the location object, the code would block that modification from happening.”).
Regarding claim 11, Kolam and Demsey teaches all the features with respect to claim 1, as outlined above.
Demsey further teaches wherein the mitigation data includes display restriction data that restricts the display of the restricted resource ([Col 9, Line 7]: “Executing the content 123 may include rendering some of the webpage content by the browser 114 and/or displaying that content on the display 113. Rendering a webpage, ad or malicious code (e.g., computer data, message, packet or a file) may include a browser or computing device requesting (e.g., making a call over a network to a source for), receiving (e.g., over a network from the source, or downloading), executing and displaying that webpage, ad or malicious code (display restriction data).”).
Regarding claim 12, Kolam and Demsey teaches all the features with respect to claim 1, as outlined above.
Demsey further teaches wherein the mitigation data includes flag data that associates a security flag with the webpage ((abstract): When a cross-origin security error results (security flag) from this execution, the cross-origin malicious code is discontinued and the cross-origin unwanted action is intercepted.).
Regarding claim 19, Kolam and Demsey teach all the features with respect to claim 13, as outlined above.
Demsey further teaches wherein the mitigation data includes at least one of notification data that notifies a user of the restricted resource ([Col 15, Line 47]: “The sandbox 184 will then wrap the potential unwanted action code (wraps written scripts of malicious creative 154 in a java script (JS) closure which creates stripped creative 185 and overrides those scripts of the ad so that they do trigger an error) and listen to that code generate errors when a failed unwanted action attempt occurs (mitigation data includes notification) and/or listen to that code access fake location objects inside of the wrapper to know if the creative 185 includes malicious code (e.g., if the unwanted action code is bad or not). Listening can be performed by using intercepting writes to certain objects and “proxying” them through executing code 182. Of the code 182 notices someone (e.g., an unwanted action or other action of malicious creative 154) (notifies a user of the restricted resource) modifying the location object, the code would block that modification from happening.”).
Demsey further teaches wherein the mitigation data includes display restriction data that restricts the display of the restricted resource ([Col 9, Line 7]: Executing the content 123 may include rendering some of the webpage content by the browser 114 and/or displaying that content on the display 113. Rendering a webpage, ad or malicious code (e.g., computer data, message, packet or a file) may include a browser or computing device requesting (e.g., making a call over a network to a source for), receiving (e.g., over a network from the source, or downloading), executing and displaying that webpage, ad or malicious code (display restriction data)”).
Demsey further teaches wherein the mitigation data includes flag data that associates a security flag with the webpage ((abstract): “When a cross-origin security error results (security flag) from this execution, the cross-origin malicious code is discontinued and the cross-origin unwanted action is intercepted.”).
Claims 2-8 and 14-17 are rejected under 35 U.S.C. 103 as being unpatentable over Kolam et al (US PG-PUB No. 20150143223 A1) in view of Demsey et al (US Patent No. 10642980 B1), in further view of Krishnan (US PG-PUB No. 20230362160 A1).
Regarding claim 2 and 14, Kolam and Demsey teach all the features with respect to claim 1 and 13, as outlined above.
Kolam and Demsey are not relying on teaching, but Krishnan teaches wherein the cross-origin URL data includes a cross- origin URL, wherein the cross-origin URL includes at least one of a protocol, a path, and a port that is different than at least one of a protocol, a path, and a port associated with the webpage (Paragraph [0029]: “The “origin” of an item of web content is typically defined by the scheme (protocol), hostname (domain), and port of the uniform resource locator (URL) used to access it. Two items of web content are thus generally considered to have the same origin only when the same scheme, hostname, and port are used to access them (Therefore, if at least one of a protocol, a path and a port of the URL is different than at least one of a protocol, a path and a port associated with the webpage, then it is a cross-origin URL). Cross-Origin Resource Sharing (CORS) defines a way in which a browser and an origin server can interact to determine whether a cross-origin request is to be allowed from a particular origin.”).
Kolam, Demsey and Krishnan are all considered to be analogous to the claimed invention because they all teach enabling and handling cross-origin resource sharing for webpage. Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the cross-origin URL data disclosed by Kolam and Demsey with adding at least one of a different protocol, path and port in cross-origin URLs disclosed by Krishnan.
One of the ordinary skills in the art would have been motivated to make this modification for security and preventing Cross-site Request Forgery attacks, as suggested by Krishnan in paragraph [0031].
Regarding claim 3 and 15, Kolam and Demsey and Krishnan, hereinafter KDK, teaches all the features with respect to claim 2 and 14, as outlined above.
Kolam further teaches wherein the determining the presence of the cross- origin URL data comprises analyzing, by the processor, requested data from the webpage data to determine if any cross-origin uniform resource locators are recited (Paragraph [0023]: “The various domains (cross-origin) associated with the referenced dependent resources of a webpage can be determined by parsing the webpage (analyzing requested data from the webpage data to determine if any cross-origin URLs are recited). For example, with reference to FIG. 2, the image file and the video file are indicated on the webpage as being stored in different locations, each specified by a URL. As each URL includes its domain information, the domains of the image and video files can be determined by parsing their respective URLs (analyzing domain information from the webpage data to determine if any cross-origin URLs are recited).”).
Kolam is not rely on teaching, but Demsey teaches wherein the independent request is generated to determine whether the resource is protected by security parameters ([Col 6, Line 12]: “Referring now to FIG. 1B, there is shown the user device 110 having browser 114 executing a protected published webpage content 123 that has the ability to detect cross-origin malicious code existing in internet advertisements.”).
One of the ordinary skills in the art would have been motivated to make this modification in order to intercept the cross-origin unwanted action, as suggested by Demsey in [Col 10, Line 1].
Regarding claim 4, KDK teaches all the features with respect to claim 3, as outlined above.
Kolam further teaches wherein the webpage data includes HTML code (Paragraph [0018]: “A webpage accessed by web browser 102 may be described by different markup languages, including Hypertext Markup Language (HTML), Extensible Markup Language (XML), and the like.”).
Regarding claim 5, KDK teaches all the features with respect to claim 3, as outlined above.
Kolam further teaches wherein the webpage data includes script code (paragraph [0018]: “The webpage may also be described by different scripting languages, including JavaScript Object Notation (JSON), and the like.”).
Regarding claim 6 and 17, KDK teaches all the features with respect to claim 2 and 14, as outlined above.
Kolam further teaches wherein the determining the presence of the cross- origin URL data comprises analyzing, by the processor, at least one returned resource as sociated with the webpage data to determine if any cross-origin URLs are recited, and wherein the independent request mirrors semantics of a source request (Paragraph [0020]: “the HTML file (webpage) may include text, dependent resources, scripts, and the like. Examples of dependent resources include images, videos, audio clips, and APIs. These dependent resources (returned resources) are resources that need to be separately transferred from origin server 104 or from other servers (returned resource associated with the webpage data are determined to be cross-origin URLs) to web browser 102. For example, as shown in FIG. 2, the list of dependent resources includes an image, which is stored at a location specified by an URL. To display the image on the webpage, web browser 102 sends a separate HTTP request message to the URL, and the image is returned in a separate HTTP response message from the URL (analyze the returned resource to determine if cross-origin URL is recited).”; Paragraph [0024]: “In the example shown in FIG. 3, web browser 102 makes same-origin request to domain 1 for resources but web browser 102 must make cross-domain requests to domain 2, domain 3 and domain 4 for resources (the independent request mirrors semantics of a source request)”).
Regarding claim 16, KDK teaches all the features with respect to claim 15, as outlined above.
Kolam further teaches wherein the webpage data includes at least one of HTML code, and script code (Paragraph [0018]: “A webpage accessed by web browser 102 may be described by different markup languages, including Hypertext Markup Language (HTML), Extensible Markup Language (XML), and the like. The webpage may also be described by different scripting languages, including JavaScript Object Notation (JSON), and the like.”).
Regarding claim 7, KDK teaches all the features with respect to claim 6, as outlined above.
Krishnan further teaches wherein the analyzing comprises analyzing metadata of the returned resource (Paragraph [0121]: “In some implementations, the preauthorization data 106 may identify one or more HTTP methods that are allowed to be used to access the resource(s) 110 at the first origin 115. HTTP defines methods to indicate the desired action to be performed on the identified resource. Examples of HTTP methods include: GET method (to retrieve a representation/copy of an indicated resource); HEAD method (to retrieve metadata for an indicated resource (metadata of the returned resource) without a representation/copy of the indicated resource);”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the returned resource disclosed by Kolam with adding metadata disclosed by Krishnan.
One of the ordinary skills in the art would have been motivated to make this modification in order to avoid retrieving a representation/copy of the returned resource for analysis purpose, as suggested by Krishnan in paragraph [0121].
Regarding claim 8, KDK teach all the features with respect to claim 7, as outlined above.
Kolam further teaches wherein the returned resource comprises at least one of HTML text, plain text, and a Json application (Paragraph [0018]: “A webpage accessed by web browser 102 (returned resource) may be described by different markup languages, including Hypertext Markup Language (HTML), Extensible Markup Language (XML), and the like. The webpage may also be described by different scripting languages, including JavaScript Object Notation (JSON), and the like.”).
Claims 9 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Kolam et al (US PG-PUB No. 20150143223 A1) and Demsey et al (US Patent No. 10642980 B1), in view of Krishnan (US PG-PUB No. 20230362160 A1), in further view of Kaube et al (US PG-PUB No. 20200053094 A1).
Regarding claim 9, KDK teach all the features with respect to claim 7, as outlined above.
KDK fails to explicitly teach, but Kaube teaches wherein the metadata comprises a URL listed as at least one of a canonical and a short (Paragraph [0059]: “operation S610 performs a lookup to locate a canonical resource metadata URL (metadata comprises a URL listed as canonical). Such canonical resource metadata may be found at the publisher's page for the article, and the URL for that page may be returned in response to the lookup. Access rights to the resource determined in operation S635 and, if access to the resource is ensured, as determined in operation S640, the canonical resource URL is returned to the calling process (process 400)”).
KDK and Kaube are all considered to be analogous to the claimed invention because they all teach retrieving digital content over a network. Therefore, it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the metadata disclosed by KDK with adding a URL listed as at least one of a canonical and a short disclosed by Kaube.
One of the ordinary skills in the art would have been motivated to make this modification in order to avoid a returned resource with fuzzy matching on bibliometric metadata or abstract text that is difficult to identify the resource, as suggested by Kaube in paragraph [0058].
Regarding claim 18, KDK teaches all the features with respect to claim 17, as outlined above.
Kolam further teaches wherein the at least one returned resource comprises at least one of HTML text, plain text, and a Json application (Paragraph [0018]: “A webpage accessed by web browser 102 (returned resource) may be described by different markup languages, including Hypertext Markup Language (HTML), Extensible Markup Language (XML), and the like. The webpage may also be described by different scripting languages, including JavaScript Object Notation (JSON), and the like.”).
Kolam fails to explicitly teach, but Krishnan teaches wherein the one or more processors analyze by analyzing metadata of the at least one returned resource (Paragraph [0121]: “In some implementations, the preauthorization data 106 may identify one or more HTTP methods that are allowed to be used to access the resource(s) 110 at the first origin 115. HTTP defines methods to indicate the desired action to be performed on the identified resource. Examples of HTTP methods include: GET method (to retrieve a representation/copy of an indicated resource); HEAD method (to retrieve metadata for an indicated resource (metadata of the returned resource) without a representation/copy of the indicated resource);”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the returned resource disclosed by Kolam with adding metadata disclosed by Krishnan.
One of the ordinary skills in the art would have been motivated to make this modification in order to avoid retrieving a representation/copy of the returned resource for analysis purpose, as suggested by Krishnan in paragraph [0121].
KDK fails to explicitly teach, but Kaube teaches wherein the metadata comprises a URL listed as at least one of a canonical and a short (Paragraph [0059]: “operation S610 performs a lookup to locate a canonical resource metadata URL (metadata comprises a URL listed as canonical). Such canonical resource metadata may be found at the publisher's page for the article, and the URL for that page may be returned in response to the lookup. Access rights to the resource determined in operation S635 and, if access to the resource is ensured, as determined in operation S640, the canonical resource URL is returned to the calling process (process 400)”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to have modified the metadata disclosed by KDK with adding a URL listed as at least one of a canonical and a short disclosed by Kaube.
One of the ordinary skills in the art would have been motivated to make this modification in order to avoid a returned resource with fuzzy matching on bibliometric metadata or abstract text that is difficult to identify the resource, as suggested by Kaube in paragraph [0058].
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. (see PTO-892 form for details)
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 JASMINE DAY whose telephone number is (571)272-0204. The examiner can normally be reached Monday - Friday 9:00 - 5:00.
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, Philip Chea can be reached at 571-272-3951. 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.
/J.M.D./Examiner, Art Unit 2499 /PHILIP J CHEA/Supervisory Patent Examiner, Art Unit 2499
Prosecution Insights