DETAILED ACTION
Status of the Claims
Claims 1-20 are pending. No claims have been canceled. No claims have been withdrawn. No claims are objected to. Claims 1, 3, 9, 11, 16, and 18 have been amended. No claims are allowable. Claims 1-20 are rejected under 35 U.S.C. § 103.
Other Prior Art
Kamath et al. (US 2008/0104198 A1) discloses a client-side browsing application caching dynamic links and associated hash values for webpage content or functionality items and requesting changed items when revised links do not match entries in the client cache ([0014]-[0015]).
Knowles et al. (US 2007/0180125 A1) discloses a mobile browser sending cache-state metadata, including hashes of document portions, to a proxy server that uses the cache information to determine whether the browser already has particular portions and thereby reduce data sent in subsequent responses ([0013]-[0015]).
Alstad et al. (US 2011/0295979 A1) discloses a server or proxy sending a first HeadStart response containing links to resources needed for a webpage before sending the full response containing the webpage content ([0011]).
Response to Arguments
The arguments of Applicant’s representative filed July 27, 2026 have been fully considered.
Rejection of Claims 1, 9, and 16 under 35 U.S.C. § 102 over Kamath.
Claim 1 was amended to require a response comprising the first subset of cache keys and associated metadata for storage at the client device while excluding application data representative of the corresponding web content. Applicant’s representative argues that Kamath does not teach or suggest the newly added subject matter and that Alstad does not cure the asserted deficiency because its HeadStart response contains links but not the resources associated with those links. However, Examiner no longer relies on either Kamath or HeadStart to reject any of the claims. Therefore, this argument is moot.
Rejection of Claims 2, 5, 6, 8, 10, 13, 14, 17, and 20 under 35 U.S.C. § 102 over Kamath.
Applicant’s representative argues claim 2 overcomes the art for the reasons given as to claim 1. However, this argument is not persuasive for the reasons provided above with respect to claim 1.
Rejection of Claims 3, 4, 7, 11, 12, 15, 18, and 19 under 35 U.S.C. § 103 over Kamath and Alstad.
Applicant’s representative argues claim 3 overcomes the art for the reasons given as to claim 1. However, this argument is not persuasive for the reasons provided above with respect to claim 1.
Claim Rejections - 35 U.S.C. § 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-20 are rejected under 35 U.S.C. § 103 as being unpatentable over Vennapusa (US 2020/0334304 A1; “Vennapusa”) in further view of Ben-Shaul et al. (US 2010/0094817 A1; “Ben-Shaul”) and Rao et al. (US 2009/0319473 A1; “Rao”).
Regarding claims 1, 9, and 16, Vennapusa teaches or suggests a method comprising:
receiving, by a server device from a client device, one or more requests for corresponding web content of a webpage application. System 16 obtains request 114 for requested webpage 115 from app 12y of user system 12 ([0100]).
wherein the one or more requests indicate metadata associated with the webpage application. Vennapusa expressly refers to metadata used to customize the mobile application as customization objects or app metadata ([0013]). A request for a webpage is used to identify updated or changed metadata/customization objects, and data associated with the request may be used to identify those objects ([0082]).
in response to receiving the one or more requests: transmitting, via the server device, a response comprising a first portion of the metadata to the client device to be stored at the client device. In response to request 114, system 16 queries metadata DB 22 for the customization objects 119A-1 associated with requested webpage 115 that have been updated since the previous time user system 12 requested that webpage, and provides those updated customization objects to user system 12 ([0100] and [0101]). User system 12 stores them upon receipt ([0107]).
in response to receiving the one or more requests: foregoing transmitting a second portion of the metadata to the client device. Customization objects 119A associated with requested webpage 115 that have not been updated since that previous request are neither queried nor provided; where none has been updated, system 16 provides requested webpage 115 without any customization objects at all ([0100] and [0101]). User system 12 instead obtains those non-updated objects locally from mobile DB 205 ([0107]).
wherein the response does not contain application data representative of the corresponding web content of the webpage application. In response to request 114, system 16 may provide updated customization objects 119A-1 to user system 12 and subsequently provide requested webpage 115, such that the response providing the updated customization objects does not contain the requested webpage ([0085]).
However, Vennapusa does not teach, but Ben-Shaul teaches, in response to receiving the one or more requests: identifying, via the server device based on the metadata, a plurality of cache keys. Upon receiving a request to download a file, the server determines the file entry representing the requested file and retrieves from that file entry the list of signatures identifying chunks of the file ([0133]). The same file entry also stores a list of signatures identifying metadata chunks generated from metadata information associated with the file, and corresponding metadata signatures are computed for those metadata chunks; because the signatures are computed for chunks generated from the metadata information, the metadata-signature list is based on the metadata information ([0197]-[0198]).
wherein the plurality of cache keys are associated with the metadata. A corresponding metadata signature is computed for each metadata chunk generated from metadata information associated with the file ([0197]-[0198]).
in response to receiving the one or more requests: receiving, from the client device, an indication of a first subset of the plurality of cache keys. In response to a request to download a file, the server sends the associated set of signatures but not the file to the client (claim 2). Claim 3 of that reference further recites that the server thereafter receives from the client a request containing one or more signatures identifying chunks not stored at the client device. Applied to Vennapusa’s request 114 for requested webpage 115, the server receives the missing-signature indication through the response sequence initiated by the webpage request (Vennapusa, [0100]; Ben-Shaul, claims 2-3).
wherein the first subset of the plurality of cache keys is not stored at the client device. The client-side repository may be a cache repository storing file chunks and their signatures ([0128]) and, during a download, each received signature is looked up in client-side repository 406a and the signatures identifying chunks missing from it are collected into a list ([0133]-[0134]); claim 3 additionally recites that the server receives from the client signatures identifying chunks not stored at the client device (claim 3).
in response to receiving the one or more requests: identifying, based on the indication, a second subset of the plurality of cache keys. The server retrieves and sends the complete signature list associated with the requested file and later receives from the client a request containing one or more signatures identifying chunks not stored at the client device (claim 3; [0133]-[0134]).
wherein the second subset of the plurality of cache keys is stored at the client device. The client-side repository may be a cache repository storing file chunks and their signatures ([0128]) and, during a download, the received signature list is looked up in client-side repository 406a to determine whether all chunks identified by the signatures are stored there, the complementary signatures being those whose chunks are already stored ([0133]-[0134]).
wherein the first portion of the metadata is associated with the first subset of the plurality of cache keys. Respective metadata signatures are computed for corresponding metadata chunks ([0197]-[0198]) and the missing chunks are identified by their respective signatures ([0133]-[0134]), such that the missing-signature subset identifies the corresponding missing metadata chunks.
wherein the second portion of the metadata is associated with the second subset of the plurality of cache keys. The same signature-to-chunk correspondence applies ([0197]-[0198]), such that the signatures having local matches identify the corresponding metadata chunks available locally.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the system of Vennapusa so that, in response to the request for the webpage, the server identifies the signatures corresponding to the metadata chunks of the webpage, receives from the client those signatures not matched in its repository, and identifies the signatures complementary to those received as those matched in the repository, each received signature identifying a metadata chunk to be transmitted and each complementary signature identifying a metadata chunk stored in the repository, as taught by Ben-Shaul, because doing so would base the transmission of metadata on the actual contents of the client-side cache rather than on whether the metadata has changed since a previous client interaction.
Additionally, the combination of Vennapusa and Ben-Shaul does not teach, but Rao teaches, wherein the response comprises the first subset of the plurality of cache keys to be stored at the client device. A hosted cache may reside on the same device as a requesting client ([0032]). When the hosted cache does not contain requested data, the client may send a second request to the application server indicating that the hosted cache does not contain the requested data; in the disclosed alternative in which that absence is separately indicated, the server may return the requested data together with a hash of the requested data ([0056]; claim 1).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Vennapusa and Ben-Shaul so that, in response to the request, the server returns to the client, together with the requested data, the hashes identifying the data the client indicated its cache does not contain, to be stored in the cache of the client, as taught by Rao, because doing so would deliver each cache key together with the customization object it indexes, allowing the user system to place each object under its key as the response arrives, without recomputing the key from the object and without inferring from the order of a multi-object response which key belongs to which object.
Regarding claims 2, 10, and 17, the combination of Vennapusa, Ben-Shaul, and Rao teaches or suggests the method of claim 1, and Vennapusa further teaches or suggests wherein the one or more requests comprise a hypertext transfer protocol (HTTP) request. User systems 12 can communicate with system 16 using HTTP, app 12y may be the HTTP client, such as a web browser, and system 16 obtains request 114 for webpage 115 from app 12y ([0030], [0034], and [0100]).
Regarding claims 3, 11, and 18, the combination of Vennapusa, Ben-Shaul, and Rao teaches or suggests the method of claim 1, and Ben-Shaul further teaches or suggests in response to identifying the plurality of cache keys, transmitting, to the client device, a first response comprising the plurality of cache keys. Upon receiving a request to download a file, the server retrieves the complete list of signatures associated with the requested file and sends the signature list to the client ([0133]). The same de-duplication technique applies to file metadata: metadata chunks are generated from the metadata information associated with the file, corresponding metadata signatures are computed, and the list of those signatures is stored in the file entry for the file, so that the list the server retrieves and sends is the metadata-signature list ([0197]-[0198]).
Ben-Shaul further teaches or suggests wherein the first response does not contain the corresponding web content of the webpage application. The response sending the signature list does not include the corresponding file chunks, which the client requests and receives only afterward, so the metadata-signature response carries no file content ([0133]-[0134]).
Ben-Shaul further teaches or suggests wherein the client device identifies the first subset of the plurality of cache keys not stored at the client device based on the first response. The client looks up each signature received in the first response in its client-side repository and generates a list of the signatures identifying the chunks missing from it ([0133]-[0134]), the same procedure applying to the metadata signatures computed for corresponding metadata chunks ([0197]-[0198]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Vennapusa, Ben-Shaul, and Rao so that, upon identifying the metadata signatures, the system provides the user system with the metadata signatures associated with the customization metadata without the requested webpage and the user system identifies, from the received metadata signatures, customization metadata not stored in the mobile DB, as taught by Ben-Shaul, because doing so would allow the determination of which customization objects require transmission to be based on the actual contents of the client-side cache rather than on whether the customization objects have changed since a previous client interaction.
Regarding claims 4, 12, and 19, the combination of Vennapusa, Ben-Shaul, and Rao teaches or suggests the method of claim 3, and Ben-Shaul further teaches or suggests wherein the first subset of the plurality of cache keys are identified by comparing each cache key stored in a local cache of the client device with the plurality of cache keys. The client-side repository may be a cache repository storing chunks and their signatures ([0128]). During a download, the client compares the received signature plurality against its client-side repository and generates a list of the signatures for which no local match is found, identifying the corresponding chunks as missing ([0133]-[0134]). The same procedure applies to the metadata signatures computed for corresponding metadata chunks, so that the received plurality is compared against the signatures stored in the local cache to identify the first subset ([0197]-[0198]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Vennapusa, Ben-Shaul, and Rao so that the user system identifies missing metadata signatures by comparing the received metadata-signature list with signatures stored in the mobile DB, as taught by Ben-Shaul, because doing so would base the determination of which customization objects are missing on the actual contents of the client-side cache rather than on server-side update history.
Regarding claims 5 and 13, the combination of Vennapusa, Ben-Shaul, and Rao teaches or suggests the method of claim 1, and Ben-Shaul further teaches or suggests wherein each of the plurality of cache keys corresponds to a respective portion of the metadata. Ben-Shaul generates one or more chunks from metadata information associated with a file and computes corresponding metadata signatures for the metadata chunks, thereby providing a respective metadata signature for each corresponding metadata chunk ([0197]-[0198]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Vennapusa, Ben-Shaul, and Rao so that the user system associates each metadata signature with its metadata chunk, as taught by Ben-Shaul, because doing so would allow each signature to identify its associated metadata chunk during cache comparison and retrieval.
Regarding claims 6, 14, and 20, the combination of Vennapusa, Ben-Shaul, and Rao teaches or suggests the method of claim 1, and the combination of Vennapusa and Ben-Shaul further teaches or suggests wherein the first subset of the plurality of cache keys comprises information corresponding to a first portion of the webpage application. Vennapusa teaches or suggests that customization objects are metadata used to customize the application, including webpage features such as fields, links, page layouts, buttons, record types, and tabs ([0077]-[0078]). Ben-Shaul teaches or suggests that respective metadata signatures identify corresponding metadata chunks ([0197]-[0198]) and that the missing-signature subset identifies chunks for which no client-side match is found ([0133]-[0134]). Applied to Vennapusa’s webpage-associated customization metadata, the first subset of metadata signatures therefore identifies customization metadata corresponding to a first portion of the webpage application.
The combination of Vennapusa and Ben-Shaul further teaches or suggests wherein the second subset comprises information corresponding to a second portion of the webpage application, different from the first portion. Ben-Shaul teaches or suggests that signatures having client-side matches identify the complementary chunks available locally ([0133]-[0134]), while Vennapusa teaches or suggests obtaining customization objects 119A associated with the requested webpage from mobile DB 205 and rendering the requested webpage using those objects together with the updated customization objects 119A-1 obtained with the requested webpage ([0107]). Because the first and second subsets are complementary and the respective metadata signatures identify respective metadata chunks, the second subset identifies different webpage-associated customization metadata from the first subset.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Vennapusa, Ben-Shaul, and Rao so that the missing-signature subset identifies customization objects customizing a first webpage feature and the complementary subset identifies customization objects customizing a second webpage feature, different from the first, as taught by the combination of Vennapusa and Ben-Shaul, because doing so would distinguish customization metadata requiring transmission from different customization metadata available in the mobile DB.
Regarding claims 7 and 15, the combination of Vennapusa, Ben-Shaul, and Rao teaches or suggests the method of claim 1, and Vennapusa further teaches or suggests wherein transmitting the metadata associated with the first subset to the client device does not include transmitting the web content of the webpage application. System 16 may provide updated customization objects 119A-1 to user system 12 and subsequently provide requested webpage 115, such that the transmission of updated customization objects does not include transmission of the requested webpage ([0085]).
Regarding claim 8, the combination of Vennapusa, Ben-Shaul, and Rao teaches or suggests the method of claim 1, and Ben-Shaul further teaches or suggests generating the plurality of cache keys by applying a hash function to the metadata. The de-duplication server generates one or more chunks from metadata information associated with a file and computes a list of corresponding metadata signatures ([0197]-[0198]). A signature is computed from the content of a set of data by applying a collision-resistant cryptographic hash function to that content ([0123]).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to further modify the system of Vennapusa, Ben-Shaul, and Rao so that the de-duplication server computes collision-resistant metadata signatures for the customization metadata, as taught by Ben-Shaul, because doing so would provide content-derived identifiers suitable for reliable signature comparison and de-duplication.
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Andrew Georgandellis whose telephone number is 571-270-3991. The examiner can normally be reached on Monday through Friday, 7:30-5:00 PM EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Tonia Dollinger, can be reached on 571-272-4170. 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 http://pair-direct.uspto.gov. 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.
/ANDREW C GEORGANDELLIS/Primary Examiner, Art Unit 2459
Prosecution Insights