DETAILED ACTION
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This action is responsive to the application filed 06/13/2023.
Claims 1-20 are presented for examination.
Information Disclosure Statement
2. The Applicants’ Information Disclosure Statement (filed 07/06/2023) has been received, entered into the record, and considered. A copy of PTO 1449 form is attached.
Drawings
3. The drawings filed 06/13/2023 are acceptable for examination purposes.
Specification
4. The 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 Objections
5. Claims 1, 12, 19, and 20 are objected to because of the following informalities:
Claim 1: “the data transformation hardware” (lines 12 and 14) should read “the data transformation accelerator circuitry”.
Claim 12: “the endpoint device” (line 14) should read “the endpoint computing device”.
Claim 19: “to deserialization” (line 2) should read “to deserialize”.
Claim 20: “the a network interface device” (line 1) should read “the network interface device”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
6. The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-11 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor, or for pre-AIA the applicant regards as the invention.
Claim 1 recites the limitations “the data” (line 7) and “the serialized data” (line 13). There are insufficient antecedent basis for these limitations in the claim.
Dependent claims 2-11 are rejected for fully incorporating the deficiencies of their base claim.
Claim Rejections - 35 USC § 102
7. 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 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Wang et al. (US 20220114270).
It is noted that any citations to specific, pages, columns, paragraphs, lines, or figures in the prior art references and any interpretation of the reference should not be considered to be limiting in any way. A reference is relevant for all it contains and may be relied upon for all that it would have reasonably suggested to one having ordinary skill in the art. See MPEP 2123.
As to claim 1:
Wang teaches an apparatus (Fig.29: system 2900) comprising:
a network interface device (Fig.29 and [0148-0152] and [0159-0161]) comprising: a processor; a first port to couple to a network; a second port to couple to an endpoint device;
data transformation accelerator circuitry to perform deserialization of a subset of the data; ([0090]: Data transformation (DT) can be used to convert data between various formats used by microservices. The conversion process can involve serialization to convert messages to a stream with a pre-defined format (protocol) to send or deserialization to convert the received stream to messages for applications to process…deserialize byte streams back to structured data [0102]: A deserialization transformation map can be used to transform a serialized string into a de-serialized object. The deserialization transformation map can include Field-ID, Type, Map offset, count (cnt), and default. Field-ID can represent an input for the accelerator to perform deserialization operation. Type can represent a data type for the accelerator to perform deserialization operation;
[0105]: The process can be performed to serialize or deserialize data by an offload engine. At 2002, a process executed by a processor prepares a transformation map. The process can be an addition to a data transformation language compiler (e.g., protobuf compiler). Software can iterate through fields in a message and generates a transformation map for either serialization or deserialization operations. A transformation map identifies the message structure, size of each fields, and the respective offsets in the output buffer for the engine to process. At 2004, software sends request (e.g., descriptor with pointer to the address and transformation map) to the accelerator engine; [0106]: At 2006, the accelerator engine (e.g., hardware) processes the descriptor and, at 2008, the transformation map. At 2010, based on the descriptor, the accelerator engine determines if a serialization or deserialization is to be performed);
parser hardware (Fig, 20: hardware parses transformation map 2008) to: parse data received at the first port from the network to determine characteristics of the data, wherein the data comprises a data structure serialized according to a serialization format ([0106]: At 2006, the accelerator engine (e.g., hardware) processes the descriptor and, at 2008, the transformation map. At 2010, based on the descriptor, the accelerator engine determines if a serialization or deserialization is to be performed; [0107]: For a serialization, 2012 can follow 2010, in which the accelerator engine can parse the transformation map. At 2014, the accelerator engine can read objects referenced by the descriptor. At 2016, based on the transformation map, the accelerator engine can process multiple fields in parallel and write the results into a staging buffer. At 2018, the accelerator engine can write the serialized string to memory. At 2020, when fields in a message are serialized (or deserialized), the final result is written into the output buffer [0108:] For a deserialization, 2050 can follow 2010. At 2050, the acceleration engine can parse the transformation map, read a string to be serialized (2252), and at 2054, parse the string of bytes based on the transformation map to generate a deserialized field at 2056),
determine that the data transformation hardware is capable of deserializing the serialized data based on the characteristics ([0093]: compute engines of such system can be configured to perform DT based on a descriptor. A descriptor can include fields such as a pointer to the serialized string, address translation information, address for the output, address for the processing status, a pointer to a transformation map, and so forth. A transformation map can enable field level parallelism for serialization or deserialization. Load queue 120 can store addresses of inputs such as input serialized string, transformation map, schema, and other data. Compute engine 130 can perform data serialization or deserialization on input data based on the transformation map; Fig, 20, [0106]: At 2006, the accelerator engine (e.g., hardware) processes the descriptor and, at 2008, the transformation map. At 2010, based on the descriptor, the accelerator engine determines if a serialization or deserialization is to be performed);
wherein the data transformation hardware deserializes the data structure to generate deserialized data, and the network interface device sends the deserialized data to the endpoint device (Fig, 20, [0107]: At 2020, when fields in a message are serialized (or deserialized), the final result is written into the output buffer at 2018; [0108]: For a deserialization, 2050 can follow 2010. At 2050, the acceleration engine can parse the transformation map, read a string to be serialized (2252), and at 2054, parse the string of bytes based on the transformation map to generate a deserialized field at 2056. At 2058, the deserialized string of bytes can be written to the staging buffer).
As to claim 2:
Wang teaches the serialization format comprises a protocol buffer ([0035], [0090], and [0109-0111]: protocol buffers).
As to claim 3:
Wang teaches the data is received based on a Remote Procedure Call (RPC) or a Google Remote Procedure Call (gRPC) protocol ([0035], [0090-0091], and [0109] and, [0154]: RPC, gRPC).
As to claim 4:
Wang teaches second data is received from the network at the first port and the parser hardware is to: parse second data in the received second data to determine characteristics of the second data ([0095] and [0107-0108]), wherein the second data comprises other serialized data according to the serialization format ([0099-0100]); and determine that the data transformation hardware does not support deserialization of the other serialization data based on the characteristics ([0104-0105]), wherein the network interface device sends the other serialized data to the endpoint device to be deserialized at the endpoint device prior to consumption of the other serialized data by the endpoint device ([0107-0108]).
As to claim 5:
Wang teaches the endpoint device implements at least a portion of a first program, the data is received from a second program implemented on another system on the network ([0090] and [0154]).
As to claim 6:
Wang teaches response data is received at the network interface device at the second port from the endpoint device based on the deserialized data, wherein the response data is serialized by the data transformation hardware to generate serialized response data, and the network interface device sends the serialized response data to the other system over the network ([0103-0104] and [0107-0108]).
As to claim 7:
Wang teaches the first program and the second program are written in different programming languages ([0090] and [0154]).As to claim 8:
Wang teaches the network interface processor further comprises protocol selector circuitry to select a particular one of a plurality of sub-protocols of an interconnect protocol to use to send the deserialized data to the endpoint device based on one or more of the characteristics of the packet or characteristics of the endpoint device ([0090], [0157-0158], and [0165]).
As to claim 9:
Wang teaches the interconnect protocol comprises a Compute Express Link (CXL)-based protocol, and the plurality of sub-protocols comprise CXL.io, CXL.mem, and CXL.cache ([0037] and [0165]).
As to claim 10:
Wang teaches the characteristics of the packet comprise a size of the packet or a quality of service associated with the packet ([0105] and [0113]), and the characteristics of the endpoint device comprise a type of the endpoint device or sub-protocols supported by the endpoint device ([0097-0098] and [0101-0102]).
As to claim 11:
Wang teaches the parser hardware is further to disaggregate data traffic fields from control fields in the packet, and the data traffic fields comprise the serialized data to be deserialized by the data transformation hardware ([0095], [0107-0108], [0111], and [0142]).
As to claim 12:
Wang teaches a method comprising:
receiving a packet from another computing system over a network at a network interface device, wherein the packet is destined for an endpoint computing device coupled to the network interface device ([0090]: Remote Procedure Calls (RPCs) can be used to communicate messages between various microservices. A microservice may have its own programming language and data format. Data transformation (DT) can be used to convert data between various formats used by microservices. The conversion process can involve serialization to convert messages to a stream with a pre-defined format (protocol) to send or deserialization to convert the received stream to messages for applications to process. As an example, Protocol Buffers (Protobuf) is a language neutral, platform-neutral mechanism to serialize structured data into byte streams and deserialize byte streams back to structured data. For example, DT can be used in connection at least with Google protobuf, Thrift, Json, and others);
parsing the packet to detect serialized data within the packet ([0106]: At 2006, the accelerator engine (e.g., hardware) processes the descriptor and, at 2008, the transformation map. At 2010, based on the descriptor, the accelerator engine determines if a serialization or deserialization is to be performed; [0107]: For a serialization, 2012 can follow 2010, in which the accelerator engine can parse the transformation map. At 2014, the accelerator engine can read objects referenced by the descriptor. At 2016, based on the transformation map, the accelerator engine can process multiple fields in parallel and write the results into a staging buffer. At 2018, the accelerator engine can write the serialized string to memory);
determining characteristics of the serialized data; determining whether deserialization hardware on the network interface device is capable of deserializing the serialized data based on the characteristics ([0093]: compute engines of such system can be configured to perform DT based on a descriptor. A descriptor can include fields such as a pointer to the serialized string, address translation information, address for the output, address for the processing status, a pointer to a transformation map, and so forth. A transformation map can enable field level parallelism for serialization or deserialization. Load queue 120 can store addresses of inputs such as input serialized string, transformation map, schema, and other data. Compute engine 130 can perform data serialization or deserialization on input data based on the transformation map; Fig, 20, [0106]: At 2006, the accelerator engine (e.g., hardware) processes the descriptor and, at 2008, the transformation map. At 2010, based on the descriptor, the accelerator engine determines if a serialization or deserialization is to be performed);
deserializing the serialized data using the deserialization hardware to generate deserialized data based on determining that the deserialization hardware on the network interface device is capable of deserializing the serialized data (Fig, 20, [0107]: At 2020, when fields in a message are serialized (or deserialized), the final result is written into the output buffer at 2018; [0108]: For a deserialization, 2050 can follow 2010. At 2050, the acceleration engine can parse the transformation map, read a string to be serialized (2252), and at 2054, parse the string of bytes based on the transformation map to generate a deserialized field at 2056. At 2058, the deserialized string of bytes can be written to the staging buffer);
determining a particular one of a plurality of sub-protocols of a multiprotocol interconnect to use to send the deserialization data; and sending the deserialized data from the network interface device to the endpoint device over the multiprotocol interconnect using the particular sub-protocol (Fig, 20, [0108]: For a deserialization, 2050 can follow 2010. At 2050, the acceleration engine can parse the transformation map, read a string to be serialized (2252), and at 2054, parse the string of bytes based on the transformation map to generate a deserialized field at 2056. At 2058, the deserialized string of bytes can be written to the staging buffer; [0158]: Network interface 2950 provides system 2900 the ability to communicate with remote devices (e.g., servers or other computing devices) over one or more networks. Network interface 2950 can include an Ethernet adapter, wireless interconnection components, cellular network interconnection components, USB (universal serial bus), or other wired or wireless standards-based or proprietary interfaces. Network interface 2950 can transmit data to a device that is in the same data center or rack or a remote device, which can include sending data stored in memory; see also, [0165-0166]).
As to claim 13:
Wang teaches the deserialization hardware is limited to deserializing serialized data meeting a particular set of conditions, and the network interface device is to send serialized data to the endpoint device for deserialization at the endpoint device when the deserialization hardware is incapable of deserializing the serialized data ([0090-0093] and [0106-0108]).
As to claim 14:
Wang teaches the multiprotocol interconnect is compliant with a CXL-based protocol, and the plurality of sub-protocols comprise CXL.io, CXL.mem, and CXL.cache ([0037] and [0165]).
As to claim 15:
Wang teaches a system (Fig.29: system 2900) comprising:
a first computing cluster (Fig.29) comprising: a set of endpoint devices; and
a network interface device (Fig.29 and [0148-0152] and [0159-0161]) comprising: a processor; a first port to couple to a network, wherein data is received from the network at the first port, wherein the data comprises serialized data and is destined for a particular one of the set of endpoint devices ([0090]: Data transformation (DT) can be used to convert data between various formats used by microservices. The conversion process can involve serialization to convert messages to a stream with a pre-defined format (protocol) to send or deserialization to convert the received stream to messages for applications to process…deserialize byte streams back to structured data);
one or more second ports to couple to the set of endpoint devices (Fig.29); deserialization/serialization acceleration circuitry to perform deserialization of the serialized data ([0090]: Data transformation (DT) can be used to convert data between various formats used by microservices. The conversion process can involve serialization to convert messages to a stream with a pre-defined format (protocol) to send or deserialization to convert the received stream to messages for applications to process…deserialize byte streams back to structured data [0102]: A deserialization transformation map can be used to transform a serialized string into a de-serialized object. The deserialization transformation map can include Field-ID, Type, Map offset, count (cnt), and default. Field-ID can represent an input for the accelerator to perform deserialization operation. Type can represent a data type for the accelerator to perform deserialization operation; [0105]: The process can be performed to serialize or deserialize data by an offload engine. At 2002, a process executed by a processor prepares a transformation map. The process can be an addition to a data transformation language compiler (e.g., protobuf compiler). Software can iterate through fields in a message and generates a transformation map for either serialization or deserialization operations. A transformation map identifies the message structure, size of each fields, and the respective offsets in the output buffer for the engine to process. At 2004, software sends request (e.g., descriptor with pointer to the address and transformation map) to the accelerator engine; [0106]: At 2006, the accelerator engine (e.g., hardware) processes the descriptor and, at 2008, the transformation map. At 2010, based on the descriptor, the accelerator engine determines if a serialization or deserialization is to be performed);
parser hardware (Fig, 20: hardware parses transformation map 2008) to: parse the serialized data to determine characteristics of the serialized data; and determine that the deserialization/serialization acceleration circuitry is capable of deserializing the serialized data based on the characteristics ([0106]: At 2006, the accelerator engine (e.g., hardware) processes the descriptor and, at 2008, the transformation map. At 2010, based on the descriptor, the accelerator engine determines if a serialization or deserialization is to be performed; [0107]: For a serialization, 2012 can follow 2010, in which the accelerator engine can parse the transformation map. At 2014, the accelerator engine can read objects referenced by the descriptor. At 2016, based on the transformation map, the accelerator engine can process multiple fields in parallel and write the results into a staging buffer. At 2018, the accelerator engine can write the serialized string to memory. At 2020, when fields in a message are serialized (or deserialized), the final result is written into the output buffer [0108:] For a deserialization, 2050 can follow 2010. At 2050, the acceleration engine can parse the transformation map, read a string to be serialized (2252), and at 2054, parse the string of bytes based on the transformation map to generate a deserialized field at 2056),
wherein the deserialization/serialization acceleration circuitry deserializes the serialized data to generate deserialized data, and the network interface device sends the deserialized data to the particular endpoint device over a multiprotocol link (Fig, 20, [0107]: At 2020, when fields in a message are serialized (or deserialized), the final result is written into the output buffer at 2018; [0108]: For a deserialization, 2050 can follow 2010. At 2050, the acceleration engine can parse the transformation map, read a string to be serialized (2252), and at 2054, parse the string of bytes based on the transformation map to generate a deserialized field at 2056. At 2058, the deserialized string of bytes can be written to the staging buffer; 0158]: Network interface 2950 provides system 2900 the ability to communicate with remote devices (e.g., servers or other computing devices) over one or more networks. Network interface 2950 can include an Ethernet adapter, wireless interconnection components, cellular network interconnection components, USB (universal serial bus), or other wired or wireless standards-based or proprietary interfaces. Network interface 2950 can transmit data to a device that is in the same data center or rack or a remote device, which can include sending data stored in memory; see also, [0165-0166]).
As to claim 16:
Wang teaches the network interface device comprises one of an infrastructure processing unit (IPU) or a smart network interface card ([0066] and [0159]).
As to claim 17:
Wang teaches the serialized data comprises protobuf data ([0035], [0090], and [0109-0111]).
As to claim 18:
Wang teaches the set of endpoint devices comprise one or more of a processor device, an accelerator device, or a memory buffer device ([0098-0101] and [0109-0111]).As to claim 19:
Wang teaches each endpoint device in the set of endpoint devices comprises deserialization/serialization logic to deserialization serialized data which cannot be deserialized using the deserialization/serialization acceleration circuitry of the network interface device ([0098-0101] and [0109-0111]).
As to claim 20:
Wang teaches the network interface device is further to: determine a particular one of a plurality of sub-protocols of a multiprotocol interconnect to use to send the deserialization data; and send the deserialized data from the network interface device to the endpoint device over the multiprotocol interconnect using the particular sub-protocol ([0157-0158]).
Conclusion
8. The prior art made of record, listed on PTO 892 provided to Applicant is considered to have relevancy to the claimed invention. Applicant should review each identified reference carefully before responding to this office action to properly advance the case in light of the prior art.
US 8763008: “processing messages using native data serialization/deserialization in a service-oriented pipeline architecture”.
US 8806506: “the SOA message processing model is independent of a specific message payload data serialization, format, or structure, as a common interface platform can generalize the serialization-specific and data format-specific processing performed for a particular message. In this manner, the serialization-specific and data format-specific processing performed behind the common interface platform can be made pluggable (e.g. processing modules for additional types of serializers/de-serializers and/or data format parsers can be added or removed without requiring a significant level of re-design or re-configuration)”.
US 11630696: “The serial interface can be enabled to send and receive data at the hardware accelerator. The serial interface enables the serialization of the data for transmitting and the deserialization of data received from outside of the hardware accelerator (for use inside the hardware accelerator). The serialization and the deserialization can depend on the schema of the messages being exchanged. For that, the present techniques can configure the serial interface in accordance with the selected schemas by, for example, generating serialization and deserialization functions or routines that are adapted to the selected schemas”.
US 12008259: “the data management system causes the network interface controller of the sender device to perform serialization, encapsulation, and transmission operations as described herein. The data management system causes the network interface controller of the recipient device to perform deserialization and decapsulation operations”.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VAN H. NGUYEN whose telephone number is (571) 272-3765. The examiner can normally be reached on Monday- Friday from 9:00AM to 5:30 PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, LEWIS BULLOCK, can be reached at telephone number (571) 272-3759. 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 Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center or Private PAIR to authorized users only. Should you have questions about access to Patent Center or the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/VAN H NGUYEN/
Primary Examiner, Art Unit 2199
Prosecution Insights