DETAILED ACTION
This action is responsive to the amendments filed 4/15/2026.
Claims 1-20 are pending. Claims 1, 9 and 15 are currently amended.
All prior rejections under 35 U.S.C. § 103 are withdrawn as necessitated by amendment.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-13, 15, 17, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Lucash, U.S. PGPUB No. 2013/0132508 (“Lucash”), in view of Zilkha, U.S. PGPUB No. 2014/0180817 (“Zilkha”), and in view of Agostino, et al., U.S. Patent No. 10,417,667 (“Agostino”).
With regard to Claim 1, Lucash teaches a system for passing data between devices, the system comprising:
one or more memories; and one or more processors, communicatively coupled to the one or more memories (Fig. 5), configured to:
transmit, to a first host device, a request for a web page to be loaded in a web browser ([0026] a client device sends a resource request to a first server for a web page);
receive, from the first host device, the web page in response to the request, wherein the web page includes code executable by the web browser and an inline content element having a source attribute ([0026]-[0027] describe that the client device receives the web page, along with instructions that execute at the client. [0028] describes that the instructions execute to create content item environments that can include an iFrame);
execute the code in an environment of the web browser ([0028] describes executing the code in the environment of the web browser);
modify, due to execution of the code, the source attribute of the inline content element to indicate a resource address appended with the user data, wherein the resource address indicates a resource ([0034] describes that the instructions populate the iFrame with an image hosted at a separate server, and append to the URL of the image demographic data that has been specified and supplied by the publisher as described at [0033]); and
transmit, as a result of modification of the source attribute and to a second host device, an additional request for the resource that passes the user data appended to the resource address to the resource ([0036] describes that the resource request for the image is made to the second server, which passes the data appended to the URL to that server).
Lucash, in view of Zilkha teaches wherein the request is responsive to a user input from a user that is authenticated to access the web page, one or more processors configured to transmit, due to execution of the code and to a service endpoint, that is an application programming interface (API) endpoint, via an asynchronous hypertext transfer protocol (HTTP) request, a data request that includes a user identifier of the user obtained from a cookie or session variable set for the user, or one or more processors configured to receive, from the service endpoint in response to the data request, user data relating to the user.
Lucash teaches at [0033] that the publisher specifies and supplies data items such as demographic information about a user that are appended to a subsequent data request as shown at [0034]-[0036]. Zilkha teaches at [0178] that a server API sends scripts to a user computing device, which are executed by the client to return an identifier of the user from a cookie. [0155] describes that user identifiers are retrieved or otherwise obtained from logged-in sessions. [0046] describes that an API server manages requests through HTTP for offers and other data, and communicates the data with users. [0031] describes that offers can be in the form of webpages and other content.
It would have been obvious to one of ordinary skill in the art at the time this application was filed to combine Lucash with Zilkha. One of skill in the art would have sought the combination, to improve user experience by enabling the appending of user information to data requests to be used to fetch content specific to the user, in addition to the data gathering function that is described in Lucash.
Lucash does not teach a cookie or session variable set for the user upon authentication. Agostino teaches at Col. 15, lines 6-21 describe that a user can log into a computer system, which causes a cookie including a user identifier to be stored on the user device. The identifier stored in the cookie can be subsequently used by other elements of the system to identify the user.
It would have been obvious to one of ordinary skill in the art at the time this application was filed to combine Agostino with Lucash and Zilkha. One of skill in the art would have sought the combination, as Zilkha is silent regarding how a user identifier is stored in a cookie, and Agostino provides a typical prior art method by which user identity information is stored in a cookie upon logging into a system. One would therefore combine this known method with Lucash and Zilkha, to produce the predictable result of storing a user identifier in a cookie as taught in Zilkha, upon a user logging into a system as taught in Agostino.
Claim 9 recites a method which is carried out by the system of Claim 1, and is similarly rejected. Claims 15 and 19 together recite a medium storing instructions which execute to implement the system of Claim 1, and is likewise rejected.
With regard to Claim 2, Zilkha teaches that the one or more processors, to transmit the data request, are configured to: transmit the data request via an application programming interface available through the service endpoint. [0046] describes that an API server manages requests through HTTP for offers and other data, and communicates the data with users.
It would have been obvious to one of ordinary skill in the art at the time this application was filed to combine Lucash and Agostino with Zilkha. One of skill in the art would have sought the combination, to improve user experience by enabling the appending of user information to data requests to be used to fetch dynamic content specific to the user, in addition to the data gathering function that is described in Lucash.
With regard to Claim 3, Lucash teaches that the inline content element is a hypertext markup language (HTML) inline frame. [0034]-[0036] describe that the modified URL is that of an iFrame.
With regard to Claim 4, Lucash, in view of Zilkha teaches that the one or more processors are further configured to: receive, from the second host device and responsive to the additional request, dynamic content for the inline content element, wherein the dynamic content is dictated by the user data. Lucash teaches at [0034]-[0036] that a data request with user-specific data appended thereto is submitted to retrieve an image. Zilkha teaches at [0178] that the scripts which access the user identifier are used to retrieve offer information specific to the user, as is described throughout Zilkha.
It would have been obvious to one of ordinary skill in the art at the time this application was filed to combine Lucash and Agostino with Zilkha. One of skill in the art would have sought the combination, to improve user experience by enabling the appending of user information to data requests to be used to fetch dynamic content specific to the user, in addition to the data gathering function that is described in Lucash.
Claim 11 recites a method which is carried out by the system of Claim 4, and is similarly rejected. Claim 20 recites a medium storing instructions which execute to implement the system of Claim 4, and is likewise rejected.
With regard to Claim 5, Lucash suggests that the one or more processors, to modify the source attribute of the inline content element, are configured to: insert the resource address appended with the user data into the source attribute of the inline content element in a document object model for the web page. [0026] describes that instructions can be in the form of scripts. [0044]-[0045] describe that the webpage content is rendered prior to the request for content from the data collection server. Therefore, the source for an inline content item such as an image can be embedded in the page DOM, as one of skill in the art understands that page rendering is carried out using a DOM, and scripts carry out operations on rendered pages through DOM.
Claim 17 recites a medium storing instructions which execute to implement the system of Claim 5, and is likewise rejected.
With regard to Claim 6, Lucash teaches that the web page is accessible at a first domain and the resource is accessible at a second domain. [0033] describes that the data collection server is a third party relative to the publisher of the website.
With regard to Claim 7, Zilkha teaches that the web page is part of an intranet website. [0116] describes that the network interface can communicate over an intranet network.
It would have been obvious to one of ordinary skill in the art at the time this application was filed to combine Lucash and Agostino with Zilkha. One of skill in the art would have sought the combination, to improve user experience by enabling the appending of user information to data requests to be used to fetch dynamic content specific to the user, in addition to the data gathering function that is described in Lucash.
With regard to Claim 8, Lucash teaches that the resource address is non-user-specific and the user data is user-specific. [0033] describes that the demographic information is retrieved pertaining to the particular user, while [0034]-[0036] describe that the image URL is to a generic image stored at the data collection server and is not specific to any particular user.
Claim 13 recites a method which is carried out by the system of Claim 8, and is similarly rejected.
With regard to Claim 10, Lucash teaches generating, due to the execution of the code, a dynamic address for the resource that includes the resource address appended with the user data. [0035] shows the URL with a dynamic parameter in which the user information is appended.
With regard to Claim 12, Lucash teaches that the document further includes non-user-specific content. [0026] describes that the content is a web page requested from a server, where no user-specific content or requests are used.
Claims 14, 16 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Lucash, in view of Zilkha, in view of Agostino, and in view of Branton, et al., U.S. PGPUB No. 2014/0143646 (“Branton”).
With regard to Claim 14, Lucash, in view of Branton teaches that the document is a web page and the resource is a serverless application. Lucash teaches at [0026] that the initial content document is a webpage. Branton teaches at [0027] that a server can reside as a node in a cloud computing infrastructure , and a module hosting a client can migrate from server to server seamlessly, thereby indicating that content serving is not dependent on provisioning a particular dedicated server therefor.
It would have been obvious to one of ordinary skill in the art at the time this application was filed to combine Lucash, Zilkha and Agostino with Branton. One of skill in the art would have sought the combination, to improve user experience by enabling data requests to be used to fetch dynamic content tailored to the user.
With regard to Claim 16, Branton teaches that the resource is a serverless application. Branton teaches at [0027] that a server can reside as a node in a cloud computing infrastructure , and a module hosting a client can migrate from server to server seamlessly, thereby indicating that content serving is not dependent on provisioning a particular dedicated server therefor.
It would have been obvious to one of ordinary skill in the art at the time this application was filed to combine Lucash, Zilkha and Agostino with Branton. One of skill in the art would have sought the combination, to improve user experience by enabling data requests to be used to fetch dynamic content tailored to the user.
With regard to Claim 18, Branton teaches that the one or more instructions, when executed by the one or more processors, further cause the device to: modify, due to the execution of the code, the document to include the user data in a placeholder element of the document. [0028] describes that specific portions of a document are designated for receiving and displaying dynamic content portions, into which the received content is inserted for display. Therefore, places are held in the document for the display of such content.
It would have been obvious to one of ordinary skill in the art at the time this application was filed to combine Lucash, Zilkha and Agostino with Branton. One of skill in the art would have sought the combination, to improve user experience by enabling data requests to be used to fetch dynamic content tailored to the user.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KEITH D BLOOMQUIST whose telephone number is (571)270-7718. The examiner can normally be reached M-F, 8:30-5 PM.
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, Kieu Vu can be reached at 571-272-4057. 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.
/KEITH D BLOOMQUIST/Primary Examiner, Art Unit 2171
6/10/2026
Prosecution Insights