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 .
Response to Application
This office action is in response to the Application filed on 06/19/2023.
Claims 1-20 are presented for examination.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/19/2023 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement has being considered by the examiner.
Drawings
The drawings submitted on 06/19/2023 are accepted.
Specification
The lengthy specification has not been checked to the extent necessary to determine the presence of all possible minor errors. Applicant’s cooperation is requested in correcting any errors of which applicant may become aware in the specification.
Claim Rejections - 35 USC § 103
In the event a determination of the status of the application as subject to AIA 35 U.S.C. 102, 103, and 112 (or as subject to pre-AIA 35 U.S.C. 102, 103, and 112) is incorrect, any correction of the statutory basis for a rejection will not be considered a new ground of rejection if the prior art relied upon and/or 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.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claims 1, 9 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Hubbard et al. (US 2004/0088432 A1; hereinafter Hubbard) in view of Peon et al. (NPL “HPACK: Header Compression for HTTP/2,” May 2015; hereinafter HPACK).
Regarding independent claims 1, 9 and 17, taking claim 1 as exemplary analysis, Hubbard teaches A computer-implemented method, comprising:
generating a translation table, wherein the translation table associates a plurality of attribute name strings with unique integer values (Hubbard teaches
Receives attribute data at management server 52 and represents the attribute data using reference characters such as integers. See Hubbard [0023]–[0026].
Provides translation table 80, implemented as a virtual dictionary, having String-to-Integer Map 82 and Integer-to-String Array List 84. See Hubbard [0028], Fig. 3.
Maps attribute-name strings, including XML attribute identifiers, to corresponding integer values. See Hubbard [0028], [0030]–[0032].
For example, maps integer “19” to the attribute-name string “LunName.” Hubbard [0031]–[0032].
Stores and updates the attribute information in memory and database 56 and makes the information accessible to GUI client 58. See Hubbard [0024]–[0025], [0034]–[0035].
Uses the integer representations to reduce storage requirements and replace repeatedly transmitted or stored variable-length strings with fixed-length references. See Hubbard [0031]–[0033].
The String-to-Integer Map necessarily assigns distinguishable integer values to different attribute-name strings so that each integer can identify its associated string. Hubbard therefore teaches generating a translation table associating a plurality of attribute-name strings with respective unique integer values and making information represented by that table available to client devices);
Hubbard independently discloses generating a translation table that maps attribute name strings to unique integer reference characters and providing that compressed integer representation to clients in a management system.
Hubbard does not expressly teach configuring the client to transmit a request containing the corresponding integer index instead of the attribute-name string.
HPACK teaches maintaining static and dynamic header tables that associate header fields with integer indexes. HPACK discloses a translation table (Static Table + Dynamic Table) that associates header/attribute name strings with unique integer indices (§§ 2.3.1–2.3.3 and Appendix A). The tables may be incrementally updated, and a header field may thereafter be transmitted as an integer index referring to the corresponding table entry (§§2.3–2.4).
An indexed header-field representation contains the index as an integer; the decoder retrieves the corresponding table entry and reconstructs the header field for processing by the application. HPACK §§3.1–3.2, 6.1.
HPACK further teaches that the encoder communicates table modifications to the decoder through encoded header blocks, thereby maintaining corresponding table information at the communicating endpoints. HPACK §§2.2-2.4, 3.2 and 6.1. Both client and server maintain synchronized copies of the table (outputting/sharing the mapping information). Clients send requests containing only the integer index (Indexed Header Field Representation, § 6.1). The receiver generates a response based on the looked-up name/value and outputs the reply
It would have been obvious to configure Hubbard’s server and clients according to HPACK’s indexed communication technique such that:
The server communicates information sufficient for the clients to maintain Hubbard’s string-to-integer mapping; A client thereafter transmits the integer assigned to an attribute-name string as part of a request; The server uses the integer to determine the associated attribute name and fulfill the request; and The server returns the resulting reply to the requesting client.
A person of ordinary skill would have been motivated to make this modification to avoid repeatedly transmitting variable-length attribute-name strings, reduce message size and bandwidth usage, decrease parsing overhead, and obtain the same compression benefits Hubbard expressly attributes to replacing strings with fixed-length integer references. See Hubbard [0031]–[0033]. HPACK demonstrates that using synchronized indexed tables at communicating endpoints was a known and predictable way to obtain those benefits.
The modification would have involved applying HPACK’s known indexed protocol technique to Hubbard’s existing string-to-integer dictionary, with each component performing its established function and producing the predictable result of integer-coded client requests.
Accordingly, the combination teaches or reasonably suggests outputting information about the translation table to client devices; in response to receiving, from a first of the client devices, a first request that includes a first of the unique integer values, generating a reply message based on the first unique integer value; and outputting the reply message to the first client device.
Hubbard’s software modules and controller additionally teach or suggest implementing the method as program instructions on a computer-readable storage medium and as processor-executable logic. Hubbard [0023]–[0028], claims 21–24. Claims 9 (CRM) and 17 (system) recite corresponding subject matter and are rejected on the same grounds.
Claims 2, 10 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over Hubbard et al. (US 2004/0088432 A1; hereinafter Hubbard) in view of Peon et al. (NPL “HPACK: Header Compression for HTTP/2,” May 2015; hereinafter HPACK), further in view of Getty et al. (NPL “Xlib - C Language X Interface, X Consortium Standard” X Version 11, release 7.7, chapter 4 , year 2002, hereinafter Xlib)
Regarding Claims 2, 10, and 18, HPACK teaches receiving a header field containing a name that is not represented by an existing table index. When the name does not match an existing entry, the name is transmitted as a literal, and a “Literal Header Field with Incremental Indexing” causes the decoder to insert the new name/value entry into the dynamic table. See §§3.2, 6.2.1, HPACK teaches detecting a new (unknown) header name string and adding it to the Dynamic Table via Literal Header Field with Incremental Indexing. The new entry associates the string with a new unique integer index and persists for the life of the connection.
Hubbard teaches adding new attribute strings to its translation table and maintaining the table for ongoing management use (more durable persistence).
The X Window System’s Xlib interface further teaches in chapter 4, section “Properties and Atoms”, XInternAtom and XInternAtoms. XInternAtom:
Receives an atom-name string from a client;
Determines whether the atom already exists;
Creates the atom when it does not exist and only_if_exists is false;
Returns the atom identifier associated with the string; and
Maintains the atom after the requesting client’s connection closes, until the last connection to the server closes.
XInternAtoms performs the same operation for an array of names and returns the corresponding array of identifiers. Thus, Xlib expressly teaches determining that a received string is not already present, adding an entry associating that string with an identifier, returning the assigned identifier, and retaining the new entry beyond the requesting client’s individual connection. The retention of the atom constitutes a predetermined persistency operation under a reasonable interpretation of that term.
It would have been obvious to incorporate Xlib’s intern-name operation into Hubbard’s String-to-Integer Map, as dynamically synchronized according to HPACK, so that a previously unknown attribute-name string is assigned a new integer, inserted into the translation table, and retained for later requests. Both Hubbard and Xlib use tables that replace textual names with identifiers, and HPACK expressly teaches dynamic table insertion for previously unindexed names.
A person of ordinary skill would have been motivated to do so to support extensible attributes introduced by clients, avoid allocating multiple identifiers to the same string, retain a consistent mapping across requests, and reduce protocol round trips. Xlib expressly recognizes the round-trip reduction obtained by processing multiple names together.
Accordingly, the combination teaches or reasonably suggests
receiving a second request from a second client device;
determining whether the second request includes an attribute name string that is not already included in the translation table; and
in response to a determination that the second request includes a first attribute name string that is not already included in the translation table: adding an entry in the translation table for the first attribute name string, and performing a predetermined persistency operation, wherein the added entry associates the first attribute name string with a second of the unique integer values.
Claims 3, 11 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Hubbard et al. (US 2004/0088432 A1; hereinafter Hubbard) in view of Peon et al. (NPL “HPACK: Header Compression for HTTP/2,” May 2015; hereinafter HPACK), further in view of Getty et al. (NPL “Xlib - C Language X Interface, X Consortium Standard” X Version 11, release 7.7, chapter 4, year 2002, hereinafter Xlib), further in view of Ling et al. (US 2005/0055508; hereinafter Ling).
Regarding Claims 3, 11, and 19
outputting an indication of the second unique integer value to the second client device, wherein the indication of the second unique integer value is piggybacked on a reply message output to the second client device.
These claims require outputting an indication of the new unique integer value that is piggybacked on a reply message.
HPACK teaches that when a new name is sent with Incremental Indexing, the peer immediately inserts it into its Dynamic Table. Subsequent messages (including replies) can reference the new integer index. This constitutes adding the new mapping information on messages exchanged between the parties.
Hubbard, HPACK, Xlib do not expressly use the term piggybacking
Ling teaches communicating pending information by piggybacking it on a reply already being transmitted to the appropriate downstream cache or client:
A side-effect notification may be piggybacked on a response to the same or another request. Ling [0022]–[0023].
An upstream cache maintains a subscription table identifying downstream caches and adds pending instructions to responses directed to those caches. Ling [0052]–[0054].
The piggybacked message may be numbered or otherwise uniquely identified. Ling [0056].
The upstream cache stores the pending information, adds it to a response, records its delivery, and retains it until the appropriate downstream entities have been notified. Ling [0060]–[0065].
Ling does not limit the piggybacked information to cache invalidation; it states that other configuration, security, administrative, and side-effect information may be propagated in the same manner. Ling [0015]–[0017], [0023].
It would have been obvious to piggyback the newly assigned integer produced by Hubbard/HPACK/Xlib on the reply already being returned to the requesting client, as taught by Ling, rather than transmit a separate mapping-update message. The motivation would have been to avoid an additional connection or round trip, reduce protocol overhead, and ensure that the identifier reaches the client with the response associated with the request that caused the identifier to be created. Ling [0050]–[0052].
Accordingly, the combination teaches or reasonably suggests outputting an indication of the second unique integer value to the second client device, wherein the indication of the second unique integer value is piggybacked on a reply message output to the second client device.
Claims 4-5, 7, 12-13, 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Hubbard et al. (US 2004/0088432 A1; hereinafter Hubbard) in view of Peon et al. (NPL “HPACK: Header Compression for HTTP/2,” May 2015; hereinafter HPACK), further in view of Getty et al. (NPL “Xlib - C Language X Interface, X Consortium Standard” X Version 11, release 7.7, chapter 4, year 2002, hereinafter Xlib), further in view of Ling et al. (US 2005/0055508; hereinafter Ling), further in view of Belshe et al. ( RFC7540: “Hypertext Transfer Protocol Version 2 (HTTP/2) (May 2015); hereinafter HTTP/2)
Regarding Claims 4, 12 and 20,
HTTP/2 in §6.5.2 teaches the client or decoder transmitting SETTINGS_HEADER_TABLE_SIZE to inform the remote encoder of the maximum header-compression table size the decoder is capable of maintaining. The encoder selects a table size no greater than the client-advertised value. The setting initially has a value of 4,096 octets and remains part of the connection state until updated.
HPACK provides mechanisms for controlling the dynamic table (SETTINGS_HEADER_TABLE_SIZE) and for determining what the peer knows. See §6.3 teaches that the encoder is constrained by the most recently received and acknowledged SETTINGS_HEADER_TABLE_SIZE. The setting therefore functions as a predetermined client-set indication of whether, and to what extent, the client is capable of caching the translation or header table. A nonzero setting indicates available table capacity during the period in which that setting remains operative.
It would have been obvious to condition the transmission of Hubbard’s newly assigned integer mapping on determining that the requesting client has advertised nonzero table-storage capacity, as taught by HTTP/2 and HPACK. Sending a reusable table index to a client unable to retain the corresponding table entry would provide no compression benefit and could cause the client and server dictionaries to become inconsistent.
Accordingly, a person of ordinary skill would have used the client’s advertised table-capacity setting as the claimed predetermined flag and would have transmitted the piggybacked identifier only while the client indicated that it could cache the translation table. The modification would predictably conserve bandwidth, avoid unusable mappings, prevent decoding errors, and respect the client’s memory limitations.
Thus, the combination renders obvious the indication of the second unique integer value is output to the second client device in response to a determination that the second client device has set a predetermined flag, wherein the predetermined flag is configured to be optionally set for a period of time that the second client device is capable of caching the translation table.
Regarding Claims 5 and 13,
Ling teaches retaining information in a pending list or queue until a response directed to the appropriate downstream cache becomes available. Ling [0054], [0060]–[0065]. When no suitable request has occurred for a predetermined time, the downstream cache may send a ping or special message, and the upstream cache then uses its response to deliver the pending information. Ling [0057].
HTTP/2 and HPACK teach that the encoder must honor the client-advertised table-size limitation and cannot operate its dynamic table beyond the decoder’s indicated storage capability. HTTP/2 §6.5.2; HPACK §§4.2, 6.3.
It would have been obvious to combine these teachings by:
Retaining the newly assigned integer as pending information when the client has not advertised translation-table storage capability;
Delaying transmission while the capability indication is absent;
Detecting a later client setting advertising table-storage capability; and
Piggybacking the pending identifier on the next reply directed to that client.
The motivation would have been to prevent loss of table synchronization and avoid transmitting an identifier the client could not use, while preserving the mapping for efficient delivery once the client becomes cache-capable. Ling’s pending-message mechanism and HTTP/2’s decoder-capacity setting perform their known functions and predictably produce the claimed delayed-delivery behavior.
Thus, the combination renders obvious delaying outputting of an indication of the second unique integer value to the second client device, in response to a determination that the second client device has not set a predetermined flag, wherein the predetermined flag is configured to be optionally set for a period of time that the second client device is capable of caching the translation table; and in response to a determination that the second client device has set the predetermined flag, outputting the indication of the second unique integer value to the second client device
Regarding Claims 7 and 15,
Hubbard teaches providing access to the attribute translation table to management clients.
HPACK teaches that the Static Table is known a priori and that table size is negotiated at connection establishment (SETTINGS).
Xlib teaches that a client can request identifiers for an array of name strings using XInternAtoms, and the server returns the associated identifiers in an array. Xlib expressly explains that the batch operation reduces client-server round trips.
HTTP/2 teaches establishing protocol state at client startup or connection establishment. Each endpoint sends a connection preface containing a SETTINGS frame that establishes the initial parameters governing the connection. The client sends its preface at connection establishment, and the server sends its SETTINGS frame as its connection preface. §§3.2–3.5.
It would have been obvious to perform Xlib’s batch name-to-identifier acquisition as part of the client’s startup or connection-initialization procedure so that the client has the translation information before sending integer-coded operational requests. In the combined system, the startup request for the set of attribute mappings constitutes a request for information about the translation table, and the returned identifier array constitutes the requested table information.
A person of ordinary skill would have been motivated to perform the synchronization at startup because:
Integer-coded requests cannot be reliably generated until the client knows the corresponding mappings;
Startup is the conventional time for establishing connection-specific protocol state;
Batch retrieval reduces round trips, as Xlib expressly teaches; and
Early synchronization avoids later decoding failures and request delays.
Selecting startup rather than a later time for an otherwise known initialization exchange would have been a predictable timing choice yielding the expected result of having the client mapping available when first needed.
Thus, the combination renders obvious the information about the translation table is output to the first client device in response to receiving a request for the translation table at a startup of the first client device.
Claims 6 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Hubbard et al. (US 2004/0088432 A1; hereinafter Hubbard) in view of Peon et al. (NPL “HPACK: Header Compression for HTTP/2,” May 2015; hereinafter HPACK), further in view of Ling et al. (US 2005/0055508; hereinafter Ling).
Regarding Claims 6 and 14,
Hubbard teaches using String-to-Integer Map 82 to determine the integer corresponding to an attribute-name string. Hubbard [0028], [0030]–[0032].
HPACK teaches determining whether a header-field name matches a name already stored in the static or dynamic table. When a match exists, the name may be represented using the integer index of the matching entry. HPACK §§2.4, 6.1–6.2.1. The receiving decoder uses that index to reconstruct the corresponding field and passes it to the application for processing. HPACK §§3.1–3.2.
Ling teaches adding numbered or identified information to the response directed to the requesting client or downstream cache. Ling [0023], [0052]–[0056], [0062]–[0065].
It would have been obvious for the server to perform the known-string path: looking up the integer for a known attribute name string, generating a reply based on that integer, and piggybacking the integer on the reply, that is
Determine that the request contains an attribute-name string already represented in Hubbard’s table;
Use the table to determine the corresponding integer;
Process the request and generate a reply using the decoded attribute;
Return the reply to the requesting client; and
Piggyback the corresponding integer on the reply so that the client can cache and use the integer in subsequent requests.
The motivation would have been to confirm the client’s mapping without a separate message, maintain synchronized dictionaries, and reduce subsequent request size.
Thus, the combination renders obvious
receiving a second request from a second client device;
determining whether the second request includes at least one of the attribute name strings in the translation table; and
in response to a determination that the second request includes a first of the attribute name strings in the translation table: using the translation table to determine a second unique integer value, wherein the second unique integer value is associated with the first attribute name string in the translation table, generating and outputting a second reply message to the second client device based on the determined second unique integer value, and piggybacking the second unique integer value on the second reply message.
Claims 8 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Hubbard et al. (US 2004/0088432 A1; hereinafter Hubbard) in view of Peon et al. (NPL “HPACK: Header Compression for HTTP/2,” May 2015; hereinafter HPACK), further in view of Ennis et al. (US 2019/0140895; hereinafter Ennis).
Regarding Claims 8 and 16, Hubbard discloses fulfilling attribute management requests; HPACK discloses normal HTTP request processing after header decoding);
Ennis teaches:
API client 402 transmitting a request for creation of a cloud resource. Ennis [0096].
API gateway 404 processing and translating the request and forwarding it to cloud service 406. Ennis [0096]–[0097].
Cloud service 406 performing the requested fulfillment operation by creating the requested instance. Ennis [0097].
Cloud service 406 returning details of the created instance, with gateway 404 forwarding a reply containing those results to API client 402. Ennis [0098].
More generally, processing an extended API request, triggering an operation, sending the resulting native request for fulfillment, and returning the confirmation response to the client. Ennis [0248]–[0249].
It would have been obvious to use the integer-coded attribute identified by Hubbard and HPACK to select or parameterize a server fulfillment operation and include the results of that operation in the reply. This represents the conventional use of a decoded client request: performing a fulfillment operation and including the results in the reply.
Thus, the combination renders obvious causing a fulfillment operation to be performed by a server to fulfill the first request, wherein the reply message includes results of the fulfillment operation.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TRACY C CHAN whose telephone number is (571)272-9992. The examiner can normally be reached on Monday - Friday 10 AM to 6 PM EST.
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, TIM VO can be reached on (571)272-3642. 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.
/TRACY C CHAN/Primary Examiner, Art Unit 2138
Prosecution Insights