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 .
This office action is in response to applicant’s amendment filed on 03/10/2026.
Claims 1-5, 7-13, and 15-22 are pending and examined.
Claims 6 and 14 are cancelled.
Response to Arguments
Applicant's arguments filed 03/10/2026 with regards to the claim objections have been fully considered and are persuasive. The claim objection for claim 7 have been withdrawn.
Applicant's arguments filed 03/10/2026 with regards to 35 U.S.C. 112(b) have been fully considered and are persuasive. The 35 U.S.C. 112(b) rejections for claims 4, 6, 12, and 14 have been withdrawn due to amendments of claims 4 and 12 and the cancellation of claims 6 and 14.
Applicant's arguments filed 03/10/2026 with regards to 35 U.S.C. 103 have been fully considered but they are not persuasive. Applicant argues that Keith “does not teach storage of the linearized at least one object as a contiguous sequence of bytes in memory for access by the second process” and that “Bodner, Keith, and Chandrasekhar fail to teach or suggest at least the cited portion of claim 1. Withdrawal of the rejection of claim 1 is requested for at least this reason.” Examiner respectfully disagrees, see U.S.C. 103 rejections below for a detailed analysis. While Keith does not explicitly teach that the object is stored as a contiguous sequence of bytes in memory, storing objects as a contiguous sequence of bytes in memory is a popular method of storing objects for transfer to a second memory address space as evidenced by the additional reference of Demchenko, who discloses objects being serialized and stored in a contiguous block of memory. Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with Demchenko because transferring objects to a second memory address space would require the object to be serialized or represented as a contiguous sequence of bytes. Then, transferring the object by copying the contiguous block of memory to a second memory address space preserves the integrity of any absolute references to memory addresses included in the object.
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.
Claim(s) 1, 3, 5-8 and 21-22 are rejected under 35 U.S.C. 103 as being unpatentable over Bodner et al. (U.S. Patent No. US 20220116259 A1), hereinafter “Bodner” in view of Keith et al. (U.S. Patent No. US 20220394034 A1), hereinafter “Keith”, Peng et al. (U.S. Patent No. US 20100083289 A1), hereinafter “Peng” and Demchenko et al. (WO Patent No. WO 2016051242 A1), hereinafter “Demchenko.”
With regards to Claim 1, Bodner teaches:
An apparatus comprising:
a network interface device (Paragraph 24, “To this end, the term network element refers to any component, e.g., BU, ROADM, optical repeater, NMS, EMS, LME, PFE, in the optical communication system 200 that includes circuitry and/or software that enables remote, network-based communication through wired or wireless connectivity.” The network element referring to any component including ROADM, optical repeaters, NMS, and PFE enabling remote, network-based communication correlates to a network interface device) comprising:
a host interface (Paragraph 27, “As discussed further below, each of the NMS components 204-1, 204-2, may collectively form a single NMS system 304 whereby users can log into any NMS component, e.g., directly via a graphical user interface (GUI), or via an API, and have requests serviced.” The users logging into a component through a GUI or API to have requests serviced correlates to a host interface);
a network interface (Paragraph 32, “As shown, the client side includes a user 429 that can utilize a client 407 to communicate with a central manager gateway 401. The client 407 may comprise a remote computing device such as a laptop, desktop computer, server computer, or smart phone with a controller/processor, memory, a user interface, and so on. The central manager gateway 401 may also be referred to as an RPC gateway 401. Note the central manager gateway 401 may be instantiated by one of the network elements, network element 406-1, or by a different server computer of the optical communication system 200.” The client communicating with a central manager gateway such as an RPC gateway correlates to a network interface);
packet processing circuitry and circuitry (Paragraph 24, “To this end, the term network element refers to any component, e.g., BU, ROADM, optical repeater, NMS, EMS, LME, PFE, in the optical communication system 200 that includes circuitry and/or software that enables remote, network-based communication through wired or wireless connectivity.” The network element referring to any component including packet forwarding engines correlates to packet processing circuitry) to:
execute a first process to provide a remote procedure call (RPC) interface for a second process (Paragraphs 41-42, “In the event the requested operation cannot be performed using local data, the RPC manager 405 can utilize the request broker 411 to communicate with the network element associated with the extracted network element address. This communication may include using an IDL-based messaging scheme to send, for example, messages 422 that comport with the CORBA protocol. For example, the request broker 411 may have a pre-compiled IDL instance (or adapter) associated with each of the network elements in the system. The request broker 411 may therefore retrieve the pre-compiled IDL from the IDL store 413 to instantiate a client with an IDL that is compatible with the target network element… In one example scenario, the request broker 411 may identify two or more remote procedure calls to perform using one or more precompiled IDL adapters in order to satisfy the request message 408.” The two or more remote procedure calls to perform to satisfy the request message correlates to a second process. The RPC manager using a request broker to instantiate a client and identify RPC calls to satisfy the request message correlates to executing a first process to provide a RPC interface for a second process),
Bodner does not explicitly teach:
a direct memory access (DMA) circuitry;
a memory allocation among the processes allow sharing access to at least one RPC message as at least one formatted object accessible from memory, and
the first process is to cause the network interface device to linearize the at least one object and store the linearized at least one object as a contiguous sequence of bytes in memory for access by the second process.
However, Keith teaches:
and a memory allocation among the processes allow sharing access to at least one RPC message as at least one formatted object accessible from memory (Paragraphs 87-88 and 95-96, “The device can include a database 232. The database 232 can be referred to as a storage device, a data repository, or a memory. The database 232 can be physical storage volumes and virtual storage volumes or arrays thereof. The database 232 can include, store, or maintain information received from the client device 208. The database 232 can store information received from the server 240. For example, the database 232 can store messages received from the client device 208 to be transmitted to the server 240 or messages received from the server 240 for forwarding to the client device 208… The database 232 can store processed data from the message modifier 228… In further detail, a device (e.g., device 216) can receive a message from a client (e.g., client device) with various fields to execute one or more routines on the a network node (e.g., a server) remote from the client, at step 405. The device can be an intermediary between the client and the server. For example, the client can execute an application (e.g., web browser, email application, local application, virtual application, among others) to establish a communication channel to the server. The device can intercept and receive the message from the client transmitting the message via the application. The message can correspond to a gRPC protocol, where the client can be a gRPC client (e.g., RPC or gRPC based client), and the server can be a gRPC server (e.g., RPC or gRPC based server) … For example, the device can receive messages from clients, process the messages, and transmit the messages to servers.” The device including a database which includes, stores, or maintains information received from the client and server correlates to the memory allocation among the processes. The device intercepting and processing the RPC message from the client before transmitting the message to the server correlates to sharing at least one RPC message. The database storing processed data from the message modifier correlates to the at least one RPC message being a formatted object accessible from memory), and the first process is to cause the network interface device to linearize the at least one object and store the linearized at least one object in memory for access by the second process (Paragraphs 61-62, 69, and 87-88, “The device 216 can include one or more of an interface 220, a detector 224, a message modifier 228, or a database 232… The interface 220 can include at least a built-in network adapter, network interface card, PCMCIA network card, EXPRESSCARD network card, card bus network adapter, wireless network adapter, USB network adapter, modem, or any other device suitable for interfacing one or more devices within the system 200 to any type of network capable of communication. The interface 220 can communicate with one or more aforementioned components to at least receive data from client devices 208 for processing and transmit data to at least the servers 240 to reduce the vulnerability and improve performance of the server 240… In some cases, when receiving a file (e.g., a proto file) from the server 240, the device 216 can compile the file into a document, such as a JSON document. The detector 224 can import the JSON document and arrange or store the JSON information (e.g., range of the values) in the database 232. The JSON information can be referred to as a memory representation of the file (e.g., a registry). The JSON information can be used as a runtime validator to ensure all fields are fully described in their definition file… The device can include a database 232. The database 232 can be referred to as a storage device, a data repository, or a memory. The database 232 can be physical storage volumes and virtual storage volumes or arrays thereof. The database 232 can include, store, or maintain information received from the client device 208. The database 232 can store information received from the server 240. For example, the database 232 can store messages received from the client device 208 to be transmitted to the server 240 or messages received from the server 240 for forwarding to the client device 208… The database 232 can include, store, or maintain other data described hereinabove, such as the categorization of each field of messages, proto files or configuration files of client devices 208 or servers 240, or stub libraries from the server 240.” The device including an interface comprising a network interface card correlates to a network interface device. The device compiling the proto file into a JSON document and storing the JSON information in the database correlates to the first process causing a network interface device to linearize at least one object and store the linearized at least one object into memory. The information stored in the database being transmitted between the client and server correlates to the object in memory being stored into memory for access by the second process).
Keith does not explicitly teach that the object [is stored] as a contiguous sequence of bytes in memory. However, storing objects as a contiguous sequence of bytes in memory is a popular method of storing objects for transfer to a second memory address space as evidenced by Demchenko (Paragraph 54, “In order to render the object susceptible for being transferred to the second memory address space 220, the object must first be serialized, i.e. represented as a contiguous sequence of bytes. According to implementations of the present technology, this is achieved by allocating a contiguous block of memory 216 sufficiently large to contain all of the data of the object, and then copying that data to the contiguous block of memory 216.” The object being serialized and stored in a contiguous block of memory correlates to storing objects as a contiguous sequence of bytes in memory).
Additionally, Peng teaches:
a direct memory access (DMA) circuitry (Paragraph 32, “The transfer between the RPC channel memory 206 and the context memory 210 may be implemented using direct memory access (DMA) hardware channels between the computer 102 and the hardware accelerator 104. DMA techniques are well known in the art.” The computer supporting transfer between the RPC channel memory and context memory using DMA hardware channels correlates to a direct memory access (DMA) circuitry);
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with an apparatus comprising a direct memory access (DMA) circuitry as taught by Peng because computers can support the transfer of RPC channel memory and context memory using DMA hardware channels, which are well known in the art. Transferring of RPC channel memory through DMA hardware channels allows the hardware accelerator to perform the functionality of the task (Peng: paragraphs 24 and 32).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with and the memory allocation among the processes provides share at least one RPC message as at least one formatted object accessible from memory as taught by Keith because the database can include, store, or maintain information from connected devices as well as policy storage, which one or more components of the device can enforce. These policies can be used for processing messages to identify invalid, unknown, duplicate or undesired fields to mitigate potential attacks (Keith: paragraph 87-88).
Lastly, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with store the at least one object as a contiguous sequence of bytes in memory as taught by Demchenko because transferring objects to a second memory address space would require the object to be serialized or represented as a contiguous sequence of bytes. Then, transferring the object by copying the contiguous block of memory to a second memory address space preserves the integrity of any absolute references to memory addresses included in the object (Demchenko: paragraphs 54 and 56).
With regards to Claim 3, Bodner in view of Keith, Demchenko and Peng teaches the system of claim 1 above. Keith further teaches:
wherein the memory allocation comprises one or more of: arena based memory allocation, non-arena based memory allocation, memory allocation near processing cores, processing requirements for security (Paragraphs 87-88, “The device can include a database 232. The database 232 can be referred to as a storage device, a data repository, or a memory. The database 232 can be physical storage volumes and virtual storage volumes or arrays thereof. The database 232 can include, store, or maintain information received from the client device 208. The database 232 can store information received from the server 240. For example, the database 232 can store messages received from the client device 208 to be transmitted to the server 240 or messages received from the server 240 for forwarding to the client device 208… The database 232 can include a policy storage 236. The policy storage 236 can store the policies for one or more components of the device 216 to enforce, such as on the messages sent from the client device 208… The database 232 can store processed data from the message modifier 228. In some cases, the database 232 can store fields removed from the messages, such as invalid fields, unknown fields, duplicate fields, or undesired fields. These fields can be processed to determine the severity of the potential attack (if any) or if these fields should be passed to the intended destination server 240 for decoding.” The device including a database which includes, stores, or maintains information received from the client and server correlates to the memory allocation. The database including a policy storage that components use to enforce data processing policies to determine the severity of a potential attack correlates to the memory allocation comprising processing requirements for security), observability and data transformation, and/or request and completion queues.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner wherein the memory allocation comprises one or more of: arena based memory allocation, non-arena based memory allocation, memory allocation near processing cores, processing requirements for security, observability and data transformation, and/or request and completion queues as taught by Keith because the database can include, store, or maintain information from connected devices as well as policy storage, which one or more components of the device can enforce. These policies can be used for processing messages to identify invalid, unknown, duplicate or undesired fields to mitigate potential attacks (Keith: paragraph 87-88).
With regards to Claim 5, Bodner in view of Keith, Demchenko and Peng teaches the system of claim 1 above. Keith further teaches:
wherein the first process and the second process are to share a linearized object structure from the memory, wherein the linearized object structure comprises an object in memory (Paragraphs 69, 87-88 and 95-96, “In some cases, when receiving a file (e.g., a proto file) from the server 240, the device 216 can compile the file into a document, such as a JSON document. The detector 224 can import the JSON document and arrange or store the JSON information (e.g., range of the values) in the database 232. The JSON information can be referred to as a memory representation of the file (e.g., a registry). The JSON information can be used as a runtime validator to ensure all fields are fully described in their definition file… The device can include a database 232. The database 232 can be referred to as a storage device, a data repository, or a memory. The database 232 can be physical storage volumes and virtual storage volumes or arrays thereof. The database 232 can include, store, or maintain information received from the client device 208. The database 232 can store information received from the server 240. For example, the database 232 can store messages received from the client device 208 to be transmitted to the server 240 or messages received from the server 240 for forwarding to the client device 208… The database 232 can include, store, or maintain other data described hereinabove, such as the categorization of each field of messages, proto files or configuration files of client devices 208 or servers 240, or stub libraries from the server 240… In further detail, a device (e.g., device 216) can receive a message from a client (e.g., client device) with various fields to execute one or more routines on the a network node (e.g., a server) remote from the client, at step 405. The device can be an intermediary between the client and the server. For example, the client can execute an application (e.g., web browser, email application, local application, virtual application, among others) to establish a communication channel to the server. The device can intercept and receive the message from the client transmitting the message via the application. The message can correspond to a gRPC protocol, where the client can be a gRPC client (e.g., RPC or gRPC based client), and the server can be a gRPC server (e.g., RPC or gRPC based server) … For example, the device can receive messages from clients, process the messages, and transmit the messages to servers” The device including a database which includes, stores, or maintains information received from the client and server such as proto or configuration files correlates to the memory. The device intercepting and processing the RPC message from the client before transmitting the message to the server correlates to the first and second process sharing an object. The message which can be a proto file in JSON format being stored in the database correlates to the two processes sharing a linearized object structure comprising an object in the memory), and wherein the object is to be processed as an object without re-arrangement of portions of the object (Paragraph 69, “In some cases, when receiving a file (e.g., a proto file) from the server 240, the device 216 can compile the file into a document, such as a JSON document. The detector 224 can import the JSON document and arrange or store the JSON information (e.g., range of the values) in the database 232. The JSON information can be referred to as a memory representation of the file (e.g., a registry). The JSON information can be used as a runtime validator to ensure all fields are fully described in their definition file. While identifying the fields in the message, the detector 224 can perform a look-up for values in the registry. The detector 224 can determine if the values from individual fields are there in the registry and that they conform to the range indicated by the registry. Based on whether the value (e.g., field value) is present and based on the conformity, the detector 224 can notify the message modifier 228 whether to remove or maintain the fields… Otherwise, if both conditions are met, the detector 224 can send an indication of valid fields to the message modifier 228.” The detector detecting that the values of the message conforms to the range and notifying the message modifier to maintain the fields correlates to wherein the object is to be processed as an object without re-arrangement of portions of the object).
Keith does not explicitly teach that the object is a C++ object with member data references that are stored in one or more contiguous memory blocks in the memory. However, the C++ language and its associated object implementation details including member data references are a popular implementation language as evidenced by Bodner (Paragraphs 20 and 32, “A first adapter of the Java adapters contains IDL definitions defined for the CORBA based C++ system, to enable compiling and general CORBA communication, and a second adapter of the Java adapters includes definitions to offer runtime services… The web services object library may therefore be developed in any number of programming languages such as, for example, C, C++, Java, Ruby, C#, VB.NET, Lua, Python, or any other suitable programming language.” The adapters and web services object library using a C++ based system correlates to using C++ objects with member data references that are stored in the memory). Additionally, storing objects in one or more contiguous memory blocks in the memory is a popular method of object storage for transmission as evidenced by Demchenko (Paragraph 54, “In order to render the object susceptible for being transferred to the second memory address space 220, the object must first be serialized, i.e. represented as a contiguous sequence of bytes. According to implementations of the present technology, this is achieved by allocating a contiguous block of memory 216 sufficiently large to contain all of the data of the object, and then copying that data to the contiguous block of memory 216.” The object being serialized and stored in a contiguous block of memory correlates to storing objects as a contiguous sequence of bytes in memory).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with wherein the first process and the second process are to share a linearized object structure from the memory, wherein the linearized object structure comprises an object in one or more contiguous memory blocks and wherein the object is to be processed as an object without re-arrangement of portions of the object as taught by Keith because the database can include, store, or maintain information from connected devices as well as policy storage, which one or more components of the device can enforce. These policies can be used for processing messages to identify invalid, unknown, duplicate or undesired fields to mitigate potential attacks (Keith: paragraph 87-88).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with store the at least one object as a contiguous sequence of bytes in memory as taught by Demchenko because transferring objects to a second memory address space would require the object to be serialized or represented as a contiguous sequence of bytes. Then, transferring the object by copying the contiguous block of memory to a second memory address space preserves the integrity of any absolute references to memory addresses included in the object (Demchenko: paragraphs 54 and 56).
With regards to Claim 7, Bodner in view of Keith, Demchenko and Peng teaches the system of claim 5 above. Keith further teaches:
comprising circuitry is to perform linearization of the at least one object and transmit the linearized at least one object to memory accessible to the first process (Paragraphs 31, 61, 69, and 87-88, “As used herein, the term “processor” describes circuitry that performs a function, an operation, or a sequence of operations… The device 216 can include one or more of an interface 220, a detector 224, a message modifier 228, or a database 232. The device 216 can include other components (e.g., processors and memory) to perform features and functionalities described herein… In some cases, when receiving a file (e.g., a proto file) from the server 240, the device 216 can compile the file into a document, such as a JSON document. The detector 224 can import the JSON document and arrange or store the JSON information (e.g., range of the values) in the database 232. The JSON information can be referred to as a memory representation of the file (e.g., a registry). The JSON information can be used as a runtime validator to ensure all fields are fully described in their definition file… The device can include a database 232. The database 232 can be referred to as a storage device, a data repository, or a memory. The database 232 can be physical storage volumes and virtual storage volumes or arrays thereof. The database 232 can include, store, or maintain information received from the client device 208. The database 232 can store information received from the server 240. For example, the database 232 can store messages received from the client device 208 to be transmitted to the server 240 or messages received from the server 240 for forwarding to the client device 208… The database 232 can include, store, or maintain other data described hereinabove, such as the categorization of each field of messages, proto files or configuration files of client devices 208 or servers 240, or stub libraries from the server 240.” The device including a processor which describes circuitry correlates to the apparatus comprising circuitry. The device compiling the proto file into a JSON document and storing the JSON information in the database correlates to circuitry to performing linearization of the at least one object and transmitting the linearized object to memory. The information stored in the database being transmitted between the client and server correlates to the object being transmitted to memory accessible to the first process).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with comprising circuitry is to perform linearization of the at least one object and transmit the linearized at least one object to memory accessible to the first process as taught by Keith because the database can include, store, or maintain information from connected devices as well as policy storage, which one or more components of the device can enforce. These policies can be used for processing messages to identify invalid, unknown, duplicate or undesired fields to mitigate potential attacks (Keith: paragraph 87-88).
With regards to Claim 8, Bodner in view of Keith, Demchenko and Peng teaches the system of claim 1 above. Bodner further teaches:
wherein the network interface device comprises one or more of:
a network interface controller (NIC), a remote direct memory access (RDMA)-enabled NIC, SmartNIC, router, switch, forwarding element (Paragraph 24, “To this end, the term network element refers to any component, e.g., BU, ROADM, optical repeater, NMS, EMS, LME, PFE, in the optical communication system 200 that includes circuitry and/or software that enables remote, network-based communication through wired or wireless connectivity.” The network element referring to any component including a packet forwarding engine correlates to the network interface device comprising one or more forwarding elements), infrastructure processing unit (IPU), data processing unit (DPU), accelerator, or network-attached appliance.
With regards to Claim 21, Bodner in view of Keith, Demchenko and Peng teaches the machine of claim 1 above. Keith further teaches:
wherein the second process is to access the at least one object in a single transaction as a valid object (Paragraphs 46-47, 69, 87-88 and 95-96, “providing an intermediary device that can intercept messages sent using a protocol, process the message, and transform the message into a message absent invalid or objectionable fields or values… The intermediary device can perform data validation by enforcing a custom range, value, and type options that can be specified in configuration file (e.g., a .proto file) accessible to the intermediary device… In some cases, when receiving a file (e.g., a proto file) from the server 240, the device 216 can compile the file into a document, such as a JSON document. The detector 224 can import the JSON document and arrange or store the JSON information (e.g., range of the values) in the database 232. The JSON information can be referred to as a memory representation of the file (e.g., a registry). The JSON information can be used as a runtime validator to ensure all fields are fully described in their definition file… The device can include a database 232. The database 232 can be referred to as a storage device, a data repository, or a memory. The database 232 can be physical storage volumes and virtual storage volumes or arrays thereof. The database 232 can include, store, or maintain information received from the client device 208. The database 232 can store information received from the server 240. For example, the database 232 can store messages received from the client device 208 to be transmitted to the server 240 or messages received from the server 240 for forwarding to the client device 208… The database 232 can include, store, or maintain other data described hereinabove, such as the categorization of each field of messages, proto files or configuration files of client devices 208 or servers 240, or stub libraries from the server 240… In further detail, a device (e.g., device 216) can receive a message from a client (e.g., client device) with various fields to execute one or more routines on the a network node (e.g., a server) remote from the client, at step 405. The device can be an intermediary between the client and the server. For example, the client can execute an application (e.g., web browser, email application, local application, virtual application, among others) to establish a communication channel to the server. The device can intercept and receive the message from the client transmitting the message via the application. The message can correspond to a gRPC protocol, where the client can be a gRPC client (e.g., RPC or gRPC based client), and the server can be a gRPC server (e.g., RPC or gRPC based server) … For example, the device can receive messages from clients, process the messages, and transmit the messages to servers” The intermediary device intercepting and transforming messages to ensure data validation based on the configuration or proto file correlates to a valid object. The device intercepting and processing the RPC message from the client before transmitting the message to the server correlates to the second process accessing the at least one object. The message which can be a proto file in JSON format being stored in the database can be retrieved from the database in a single transaction and would therefore correlate to wherein the second process is to access the at least one object in a single transaction as a valid object).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with wherein the second process is to access the at least one object in a single transaction as a valid object as taught by Keith because the database can include, store, or maintain information from connected devices as well as policy storage, which one or more components of the device can enforce. These policies can be used for processing messages to identify invalid, unknown, duplicate or undesired fields to mitigate potential attacks. Intermediary devices can reduce node or server vulnerabilities by detecting and removing redundant or unwanted fields, validating field content for known vulnerabilities and removing attack vectors such as injection attacks (Keith: paragraphs 46-47 and 87-88).
With regards to Claim 22, Bodner in view of Keith, Demchenko and Peng teaches the machine of claim 1 above. Keith further teaches:
wherein the at least one formatted object comprises a function and data (Paragraphs 63 and 87, “Based on the type of message indicated by, for example, the header of the message, the detector 224 can decode or extract one or more fields from a message, among other contents. The fields can include name-value pairs, such as field name or field value. The message can indicate a function or an instruction for the server 240 to execute or perform… The device can include a database 232. The database 232 can be referred to as a storage device, a data repository, or a memory. The database 232 can be physical storage volumes and virtual storage volumes or arrays thereof. The database 232 can include, store, or maintain information received from the client device 208. The database 232 can store information received from the server 240. For example, the database 232 can store messages received from the client device 208 to be transmitted to the server 240 or messages received from the server 240 for forwarding to the client device 208.” The device including a database which can store messages received from the client device or server correlates to the formatted object. The message including name-value pair fields and functions for the server to execute correlates to the at least one formatted object comprises a function and data).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with wherein the at least one formatted object comprises a function and data as taught by Keith because the database can include, store, or maintain information from connected devices such as messages received from the client device or server as well as policy storage, which one or more components of the device can enforce. These policies can be used for processing messages to identify invalid, unknown, duplicate or undesired fields to mitigate potential attacks. Messages can further include fields such as name-value pairs and functions or instructions for a server to execute or perform, which can be validated by a detector (Keith: paragraphs 63 and 87-88).
Claim(s) 2 and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Bodner in view of Keith, Peng, Demchenko, and Takeda et al. (U.S. Patent No. US 20200310937 A1), hereinafter “Takeda.”
With regards to Claim 2, Bodner in view of Keith, Demchenko and Peng teaches the system of claim 1 above. Bodner in view of Keith and Peng does not explicitly teach:
wherein to provide the RPC interface, the first process is to utilize one or more accelerator devices that perform one or more of: data transformation, encryption, reliable transport, load balancing, traffic routing, secure key storage, authentication, and/or observability.
However, Takeda teaches:
wherein to provide the RPC interface, the first process is to utilize one or more accelerator devices that perform one or more of: data transformation, encryption, reliable transport, load balancing, traffic routing, secure key storage, authentication, and/or observability (Paragraph 53, “The RPC library 223 is a library used for the RPC. In the RPC library 223, an RPC server 2231 and a reexecution RPC server 2232 are generated by the code generator 155 of the host PC 10. Upon receipt of a function process request issued by the RPC client 1541, the RPC server 2231 performs the function process. The function can offload the process onto the hardware accelerator, the DSP and the like, by calling the image processing library 222.” The RPC server performing the function process which offloads the process onto the hardware accelerator correlates to the first process utilizing one or more accelerator devices to perform one or more of load balancing).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with wherein to provide the RPC interface, the first process is to utilize one or more accelerator devices that perform one or more of: data transformation, encryption, reliable transport, load balancing, traffic routing, secure key storage, authentication, and/or observability as taught by Takeda because the performance of a pipeline-parallelized application can be more correctly estimated using an accelerator by profiling resource contention. The profiled resource contention can be used to group RPC nodes to reduce idle time and increase utilization of worker threads (Takeda: paragraphs 128-131).
With regards to Claim 4, Bodner in view of Keith, Demchenko and Peng teaches the system of claim 1 above. Bodner in view of Keith and Peng does not explicitly teach:
wherein the first and second processes are partitioned and wherein a shepherding process is to provide communication between the partitioned first and second processes to utilize direct memory access (DMA), shared memory, polling threads, and/or timers.
However, Takeda teaches:
wherein the first and second processes are partitioned and wherein a shepherding process is to provide communication between the partitioned first and second processes to utilize direct memory access (DMA), shared memory, polling threads, and/or timers (Paragraphs 81, 83 and 105, “In Step S114, the application 152 passes the request data (the RPC node graph 1522, the input period, and the number of repetitions), as arguments, to the reexecuter 224 on the board 20 via the reexecution RPC client 1542 and the communication. driver in the OS 151… As described later in detail, the reexecuter 224 allocates a node to a thread, adopts, as an input, the input history stored as the snapshot 22311, and executes the process of the RPC node graph 1522… In Step S207, the reexecuter 224 registers the allocated RPC node (beginning node) as a node to be periodically activated by the timer thread. Subsequently, the processing transitions to Step S209. The worker thread corresponding to the beginning node is the backward-dependent thread of the timer thread.” The reexecuter receiving the request data and executing the process in the RPC node graph through worker threads correlates to the first and second processes that are partitioned. The reexecutor registering an allocated RPC node to be periodically activated by the timer thread correlates to a shepherding layer providing communication between the partitioned processes to utilize timers).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with wherein the first and second processes are partitioned and wherein a shepherding process is to provide communication between the partitioned first and second processes to utilize direct memory access (DMA), shared memory, polling threads, and/or timers as taught by Takeda because managing the number of worker threads or the cores in execution of the processes prevents them from getting exhausted, which decreases performance. Load imbalance between worker threads can also cause similar issues, and coalescing dependent nodes into one group or integrated RPC node based on the utilization of the thread allows the node to be periodically activated by timer threads to efficiently finish processing for all worker threads (Takeda: paragraphs 95-98 and 110).
Claim(s) 10 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Bodner in view of Keith, Demchenko, and Takeda.
With regards to Claim 10, Bodner in view of Keith, and Demchenko teaches the machine of claim 9 above. Bodner in view of Keith and Demchenko does not explicitly teach:
wherein to provide the RPC interface, the second process is to utilize one or more accelerator devices that perform one or more of: data transformation, encryption, reliable transport, load balancing, traffic routing, secure key storage, authentication, and/or observability.
However, Takeda teaches:
wherein to provide the RPC interface, the second process is to utilize one or more accelerator devices that perform one or more of: data transformation, encryption, reliable transport, load balancing, traffic routing, secure key storage, authentication, and/or observability (Paragraph 53, “The RPC library 223 is a library used for the RPC. In the RPC library 223, an RPC server 2231 and a reexecution RPC server 2232 are generated by the code generator 155 of the host PC 10. Upon receipt of a function process request issued by the RPC client 1541, the RPC server 2231 performs the function process. The function can offload the process onto the hardware accelerator, the DSP and the like, by calling the image processing library 222.” The RPC server performing the function process which offloads the process onto the hardware accelerator correlates to the second process utilizing one or more accelerator devices to perform one or more of load balancing).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with wherein to provide the RPC interface, the second process is to utilize one or more accelerator devices that perform one or more of: data transformation, encryption, reliable transport, load balancing, traffic routing, secure key storage, authentication, and/or observability as taught by Takeda because the performance of a pipeline-parallelized application can be more correctly estimated using an accelerator by profiling resource contention. The profiled resource contention can be used to group RPC nodes to reduce idle time and increase utilization of worker threads (Takeda: paragraphs 128-131).
With regards to Claim 12, Bodner in view of Keith and Demchenko teaches the system of claim 1 above. Bodner in view of Keith and Demchenko does not explicitly teach:
wherein the first and second processes are partitioned and wherein a shepherding process is to provide communication between the partitioned first and second processes to utilize direct memory access (DMA), shared memory, polling threads, and/or timers.
However, Takeda teaches:
wherein the first and second processes are partitioned and wherein a shepherding process is to provide communication between the partitioned first and second processes to utilize direct memory access (DMA), shared memory, polling threads, and/or timers (Paragraphs 81, 83 and 105, “In Step S114, the application 152 passes the request data (the RPC node graph 1522, the input period, and the number of repetitions), as arguments, to the reexecuter 224 on the board 20 via the reexecution RPC client 1542 and the communication. driver in the OS 151… As described later in detail, the reexecuter 224 allocates a node to a thread, adopts, as an input, the input history stored as the snapshot 22311, and executes the process of the RPC node graph 1522… In Step S207, the reexecuter 224 registers the allocated RPC node (beginning node) as a node to be periodically activated by the timer thread. Subsequently, the processing transitions to Step S209. The worker thread corresponding to the beginning node is the backward-dependent thread of the timer thread.” The reexecuter receiving the request data and executing the process in the RPC node graph through worker threads correlates to the first and second processes that are partitioned. The reexecutor registering an allocated RPC node to be periodically activated by the timer thread correlates to a shepherding layer providing communication between the partitioned processes to utilize timers).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with wherein the first and second processes are partitioned and wherein a shepherding process is to provide communication between the partitioned first and second processes to utilize direct memory access (DMA), shared memory, polling threads, and/or timers as taught by Takeda because managing the number of worker threads or the cores in execution of the processes prevents them from getting exhausted, which decreases performance. Load imbalance between worker threads can also cause similar issues, and coalescing dependent nodes into one group or integrated RPC node based on the utilization of the thread allows the node to be periodically activated by timer threads to efficiently finish processing for all worker threads (Takeda: paragraphs 95-98 and 110).
Claim(s) 9, 11, 13, and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over Bodner in view of Keith and Demchenko.
With regards to Claim 9, Bodner teaches:
At least one non-transitory computer-readable medium comprising instructions stored thereon, that if executed by one or more processors, cause the one or more processors to:
a compiler to generate first and second processes (Fig. 6, paragraphs 34 and 41-42, “The request broker 411 may include a general central manager IDL parser, which is discussed in greater detail below with reference to FIG. 6. For example, the IDL parser may utilize a precompiled IDL, also known as an adapter, output from an CORBA IDL… In the event the requested operation cannot be performed using local data, the RPC manager 405 can utilize the request broker 411 to communicate with the network element associated with the extracted network element address. This communication may include using an IDL-based messaging scheme to send, for example, messages 422 that comport with the CORBA protocol. For example, the request broker 411 may have a pre-compiled IDL instance (or adapter) associated with each of the network elements in the system. The request broker 411 may therefore retrieve the pre-compiled IDL from the IDL store 413 to instantiate a client with an IDL that is compatible with the target network element… In one example scenario, the request broker 411 may identify two or more remote procedure calls to perform using one or more precompiled IDL adapters in order to satisfy the request message 408.” The request broker including a general central manager IDL parser instantiating a client and identifying RPC calls to satisfy the request message correlates to a compiler generating the first and second processes),
the second process is to provide a remote procedure call (RPC) interface for the first process (Paragraphs 41-42, “In the event the requested operation cannot be performed using local data, the RPC manager 405 can utilize the request broker 411 to communicate with the network element associated with the extracted network element address. This communication may include using an IDL-based messaging scheme to send, for example, messages 422 that comport with the CORBA protocol. For example, the request broker 411 may have a pre-compiled IDL instance (or adapter) associated with each of the network elements in the system. The request broker 411 may therefore retrieve the pre-compiled IDL from the IDL store 413 to instantiate a client with an IDL that is compatible with the target network element… In one example scenario, the request broker 411 may identify two or more remote procedure calls to perform using one or more precompiled IDL adapters in order to satisfy the request message 408.” The two or more remote procedure calls to perform to satisfy the request message correlates to a first process. The RPC manager using a request broker to instantiate a client and identify RPC calls to satisfy the request message correlates to a second process to provide a RPC interface for a first process),
Bodner does not explicitly teach:
a memory allocation among the processes provides share at least one RPC message as at least one formatted object accessible from memory, and
the first process is to cause linearization of the at least one object and storage of the linearized at least one object as a contiguous sequence of bytes in the memory for access by the second process.
However, Keith teaches:
a memory allocation among the processes provides share at least one RPC message as at least one formatted object accessible from memory (Paragraphs 87-88 and 95-96, “The device can include a database 232. The database 232 can be referred to as a storage device, a data repository, or a memory. The database 232 can be physical storage volumes and virtual storage volumes or arrays thereof. The database 232 can include, store, or maintain information received from the client device 208. The database 232 can store information received from the server 240. For example, the database 232 can store messages received from the client device 208 to be transmitted to the server 240 or messages received from the server 240 for forwarding to the client device 208… The database 232 can store processed data from the message modifier 228… In further detail, a device (e.g., device 216) can receive a message from a client (e.g., client device) with various fields to execute one or more routines on the a network node (e.g., a server) remote from the client, at step 405. The device can be an intermediary between the client and the server. For example, the client can execute an application (e.g., web browser, email application, local application, virtual application, among others) to establish a communication channel to the server. The device can intercept and receive the message from the client transmitting the message via the application. The message can correspond to a gRPC protocol, where the client can be a gRPC client (e.g., RPC or gRPC based client), and the server can be a gRPC server (e.g., RPC or gRPC based server) … For example, the device can receive messages from clients, process the messages, and transmit the messages to servers.” The device including a database which includes, stores, or maintains information received from the client and server correlates to the memory allocation among the processes. The device intercepting and processing the RPC message from the client before transmitting the message to the server correlates to sharing at least one RPC message. The database storing processed data from the message modifier correlates to the at least one RPC message being a formatted object accessible from memory), and the first process is to cause linearization of the at least one object and storage of the linearized at least one object in the memory for access by the second process (Paragraphs 69 and 87-88, “In some cases, when receiving a file (e.g., a proto file) from the server 240, the device 216 can compile the file into a document, such as a JSON document. The detector 224 can import the JSON document and arrange or store the JSON information (e.g., range of the values) in the database 232. The JSON information can be referred to as a memory representation of the file (e.g., a registry). The JSON information can be used as a runtime validator to ensure all fields are fully described in their definition file… The device can include a database 232. The database 232 can be referred to as a storage device, a data repository, or a memory. The database 232 can be physical storage volumes and virtual storage volumes or arrays thereof. The database 232 can include, store, or maintain information received from the client device 208. The database 232 can store information received from the server 240. For example, the database 232 can store messages received from the client device 208 to be transmitted to the server 240 or messages received from the server 240 for forwarding to the client device 208… The database 232 can include, store, or maintain other data described hereinabove, such as the categorization of each field of messages, proto files or configuration files of client devices 208 or servers 240, or stub libraries from the server 240.” The device compiling the proto file into a JSON document and storing the JSON information in the database correlates to the first process causing a network interface device to linearize at least one object and store the linearized at least one object into memory. The information stored in the database being transmitted between the client and server correlates to the object in memory being stored into memory for access by the second process).
Keith does not explicitly teach that the object [is stored] as a contiguous sequence of bytes in memory. However, storing objects as a contiguous sequence of bytes in memory is a popular method of storing objects for transfer to a second memory address space as evidenced by Demchenko (Paragraph 54, “In order to render the object susceptible for being transferred to the second memory address space 220, the object must first be serialized, i.e. represented as a contiguous sequence of bytes. According to implementations of the present technology, this is achieved by allocating a contiguous block of memory 216 sufficiently large to contain all of the data of the object, and then copying that data to the contiguous block of memory 216.” The object being serialized and stored in a contiguous block of memory correlates to storing objects as a contiguous sequence of bytes in memory).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with a memory allocation among the processes provides share at least one RPC message as at least one formatted object accessible from memory, and the first process is to cause linearization of the at least one object and storage of the linearized at least one object as a contiguous sequence of bytes in the memory for access by the second process as taught by Keith because the database can include, store, or maintain information from connected devices as well as policy storage, which one or more components of the device can enforce. These policies can be used for processing messages to identify invalid, unknown, duplicate or undesired fields to mitigate potential attacks. Processing shared messages can reduce the vulnerability to the end or other network node, increase the performance of the server and improve latency of the node (Keith: paragraph 87-88 and 96).
Lastly, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with store the at least one object as a contiguous sequence of bytes in memory as taught by Demchenko because transferring objects to a second memory address space would require the object to be serialized or represented as a contiguous sequence of bytes. Then, transferring the object by copying the contiguous block of memory to a second memory address space preserves the integrity of any absolute references to memory addresses included in the object (Demchenko: paragraphs 54 and 56).
With regards to Claim 11, Bodner in view of Keith and Demchenko teaches the system of claim 9 above. Keith further teaches:
wherein the memory allocation comprises one or more of: arena based memory allocation, non-arena based memory allocation, memory allocation near processing cores, processing requirements for security (Paragraphs 87-88, “The device can include a database 232. The database 232 can be referred to as a storage device, a data repository, or a memory. The database 232 can be physical storage volumes and virtual storage volumes or arrays thereof. The database 232 can include, store, or maintain information received from the client device 208. The database 232 can store information received from the server 240. For example, the database 232 can store messages received from the client device 208 to be transmitted to the server 240 or messages received from the server 240 for forwarding to the client device 208… The database 232 can include a policy storage 236. The policy storage 236 can store the policies for one or more components of the device 216 to enforce, such as on the messages sent from the client device 208… The database 232 can store processed data from the message modifier 228. In some cases, the database 232 can store fields removed from the messages, such as invalid fields, unknown fields, duplicate fields, or undesired fields. These fields can be processed to determine the severity of the potential attack (if any) or if these fields should be passed to the intended destination server 240 for decoding.” The device including a database which includes, stores, or maintains information received from the client and server correlates to the memory allocation. The database including a policy storage that components use to enforce data processing policies to determine the severity of a potential attack correlates to the memory allocation comprising processing requirements for security), observability and data transformation, and/or request and completion queues.
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner wherein the memory allocation comprises one or more of: arena based memory allocation, non-arena based memory allocation, memory allocation near processing cores, processing requirements for security, observability and data transformation, and/or request and completion queues as taught by Keith because the database can include, store, or maintain information from connected devices as well as policy storage, which one or more components of the device can enforce. These policies can be used for processing messages to identify invalid, unknown, duplicate or undesired fields to mitigate potential attacks (Keith: paragraph 87-88).
With regards to Claim 13, Bodner in view of Keith, and Demchenko teaches the system of claim 9 above. Keith further teaches:
wherein the linearized at least one object comprises an object and wherein the first process and the second process are to share the linearized at least one object in memory (Paragraphs 69, 87-88 and 95-96, “In some cases, when receiving a file (e.g., a proto file) from the server 240, the device 216 can compile the file into a document, such as a JSON document. The detector 224 can import the JSON document and arrange or store the JSON information (e.g., range of the values) in the database 232. The JSON information can be referred to as a memory representation of the file (e.g., a registry). The JSON information can be used as a runtime validator to ensure all fields are fully described in their definition file… The device can include a database 232. The database 232 can be referred to as a storage device, a data repository, or a memory. The database 232 can be physical storage volumes and virtual storage volumes or arrays thereof. The database 232 can include, store, or maintain information received from the client device 208. The database 232 can store information received from the server 240. For example, the database 232 can store messages received from the client device 208 to be transmitted to the server 240 or messages received from the server 240 for forwarding to the client device 208… The database 232 can include, store, or maintain other data described hereinabove, such as the categorization of each field of messages, proto files or configuration files of client devices 208 or servers 240, or stub libraries from the server 240… In further detail, a device (e.g., device 216) can receive a message from a client (e.g., client device) with various fields to execute one or more routines on the a network node (e.g., a server) remote from the client, at step 405. The device can be an intermediary between the client and the server. For example, the client can execute an application (e.g., web browser, email application, local application, virtual application, among others) to establish a communication channel to the server. The device can intercept and receive the message from the client transmitting the message via the application. The message can correspond to a gRPC protocol, where the client can be a gRPC client (e.g., RPC or gRPC based client), and the server can be a gRPC server (e.g., RPC or gRPC based server) … For example, the device can receive messages from clients, process the messages, and transmit the messages to servers” The device including a database which includes, stores, or maintains information received from the client and server such as proto or configuration files correlates to one or more contiguous memory blocks in the memory. The device intercepting and processing the RPC message from the client before transmitting the message to the server correlates to the first and second process sharing an object. The message which can be a proto file in JSON format being stored in the database correlates to the two processes sharing a linearized object structure comprising an object in one or more contiguous memory blocks in the memory),
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with wherein the first process and the second process are to share a linearized object structure from the memory, wherein the linearized object structure comprises an object in one or more contiguous memory blocks and wherein the object is to be processed as an object without re-arrangement of portions of the object as taught by Keith because the database can include, store, or maintain information from connected devices as well as policy storage, which one or more components of the device can enforce. These policies can be used for processing messages to identify invalid, unknown, duplicate or undesired fields to mitigate potential attacks (Keith: paragraph 87-88).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with store the at least one object as a contiguous sequence of bytes in memory as taught by Demchenko because transferring objects to a second memory address space would require the object to be serialized or represented as a contiguous sequence of bytes. Then, transferring the object by copying the contiguous block of memory to a second memory address space preserves the integrity of any absolute references to memory addresses included in the object (Demchenko: paragraphs 54 and 56).
With regards to Claim 15, Bodner in view of Keith, and Demchenko teaches the system of claim 13 above. Keith further teaches:
comprising instructions stored thereon, that if executed by one or more processors, cause the one or more processors to:
cause transmission of the linearized at least one object to memory accessible to the second process (Paragraphs 31, 61, 69, and 87-88, “As used herein, the term “processor” describes circuitry that performs a function, an operation, or a sequence of operations… The device 216 can include one or more of an interface 220, a detector 224, a message modifier 228, or a database 232. The device 216 can include other components (e.g., processors and memory) to perform features and functionalities described herein… In some cases, when receiving a file (e.g., a proto file) from the server 240, the device 216 can compile the file into a document, such as a JSON document. The detector 224 can import the JSON document and arrange or store the JSON information (e.g., range of the values) in the database 232. The JSON information can be referred to as a memory representation of the file (e.g., a registry). The JSON information can be used as a runtime validator to ensure all fields are fully described in their definition file… The device can include a database 232. The database 232 can be referred to as a storage device, a data repository, or a memory. The database 232 can be physical storage volumes and virtual storage volumes or arrays thereof. The database 232 can include, store, or maintain information received from the client device 208. The database 232 can store information received from the server 240. For example, the database 232 can store messages received from the client device 208 to be transmitted to the server 240 or messages received from the server 240 for forwarding to the client device 208… The database 232 can include, store, or maintain other data described hereinabove, such as the categorization of each field of messages, proto files or configuration files of client devices 208 or servers 240, or stub libraries from the server 240.” The device including a processor which describes circuitry correlates to the apparatus comprising circuitry. The device compiling the proto file into a JSON document and storing the JSON information in the database correlates to circuitry to performing linearization of the at least one object and transmitting the linearized object to memory. The information stored in the database being transmitted between the client and server correlates causing transmission of the linearized at least one object to memory accessible to the second process).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with comprising instructions stored thereon, that if executed by one or more processors, cause the one or more processors to: cause transmission of the linearized at least one object to memory accessible to the second process as taught by Keith because the database can include, store, or maintain information from connected devices as well as policy storage, which one or more components of the device can enforce. These policies can be used for processing messages to identify invalid, unknown, duplicate or undesired fields to mitigate potential attacks (Keith: paragraph 87-88).
With regards to Claim 16, Bodner in view of Keith and Demchenko teaches the machine of claim 13 above. Bodner further teaches:
wherein the compiler is to generate programming language classes and object access methods for a linearized structure for a software and data structure template (Paragraph 85, “Additionally, by annotating proto file fields with custom options, the device 216 can generate transform classes of API parameters annotated by the options based on external events. For example, the device 216 can translate all localizable strings into different programming languages or restrict access to classes of fields based on Geo-Location. In this case, the device 216 can compare conditions of, for example, client device 208 to determine types or classes of fields restricted by the server 240, among other parameters configured by the administrator of the server 240.” The device generating transform classes based on the proto file fields and determining types or classes of fields restricted by the server correlates to the compiler generating programming language classes and object access methods for a linearized structure for a software and data structure template) for linearization of the at least one object (Paragraphs 61, 69, and 87-88, “The device 216 can include one or more of an interface 220, a detector 224, a message modifier 228, or a database 232. The device 216 can include other components (e.g., processors and memory) to perform features and functionalities described herein… In some cases, when receiving a file (e.g., a proto file) from the server 240, the device 216 can compile the file into a document, such as a JSON document. The detector 224 can import the JSON document and arrange or store the JSON information (e.g., range of the values) in the database 232. The JSON information can be referred to as a memory representation of the file (e.g., a registry). The JSON information can be used as a runtime validator to ensure all fields are fully described in their definition file… The device can include a database 232. The database 232 can be referred to as a storage device, a data repository, or a memory. The database 232 can be physical storage volumes and virtual storage volumes or arrays thereof. The database 232 can include, store, or maintain information received from the client device 208. The database 232 can store information received from the server 240. For example, the database 232 can store messages received from the client device 208 to be transmitted to the server 240 or messages received from the server 240 for forwarding to the client device 208… The database 232 can include, store, or maintain other data described hereinabove, such as the categorization of each field of messages, proto files or configuration files of client devices 208 or servers 240, or stub libraries from the server 240.” The device compiling the proto file into a JSON document and storing the JSON information in the database correlates to linearization of the at least one object).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with wherein the compiler is to generate programming language classes and object access methods for a linearized structure for a software and data structure template for input to the network interface device and circuitry to perform linearization of the at least one object as taught by Keith because the servers can specify classes or types of fields that are restricted, along with other parameters configured by the administrator of the server. Proto file fields can also be annotated with custom options to generate transform classes based on external events for improved flexibility (Keith: paragraph 85).
With regards to Claim 17, Bodner teaches:
A method comprising:
a first process, executed by a server, accessing a second process, (Fig. 4, paragraphs 41-42 and 45, “In the event the requested operation cannot be performed using local data, the RPC manager 405 can utilize the request broker 411 to communicate with the network element associated with the extracted network element address. This communication may include using an IDL-based messaging scheme to send, for example, messages 422 that comport with the CORBA protocol. For example, the request broker 411 may have a pre-compiled IDL instance (or adapter) associated with each of the network elements in the system. The request broker 411 may therefore retrieve the pre-compiled IDL from the IDL store 413 to instantiate a client with an IDL that is compatible with the target network element… In one example scenario, the request broker 411 may identify two or more remote procedure calls to perform using one or more precompiled IDL adapters in order to satisfy the request message 408… Accordingly, one request message 408 may cause communication of messages 422 with two or more network elements by calling/executing one or more remote procedure calls of the two or more network elements… The network elements, e.g., network elements 406-1 to 406-3, may therefore derive the IDL specific to their device type to ensure the proper interfaces are available to service requests. In another example, the RPC manager A IDL 604 and the RPC manager B IDL 605 may define ‘stub’ or placeholder functions that may set dynamically at runtime to allow users to customize the logic associated with each predetermined placeholder function. Accordingly, each client/server instance can load two or more precompiled IDL adapters, namely at least a first IDL adapter that defines common/default methods and functions to communicate, e.g., via CORBA, and a second IDL adapter with stub/placeholder functions to allow for runtime customization of the exposed RPC operations.” The two or more remote procedure calls to perform to satisfy the request message correlates to a first process. The two or more remote procedure calls being executed by two or more network elements, which are located on the server side as seen in Fig. 4, correlates to a first process executed by the server. The RPC manager using a request broker to instantiate a client and identify RPC calls to satisfy the request message correlates to a second process. The RPC managers defining stub functions to communicate for each client/server instance correlates to a first process accessing a second process), wherein the second process provides a remote procedure call (RPC) interface for the first process (Paragraphs 41-42, “In the event the requested operation cannot be performed using local data, the RPC manager 405 can utilize the request broker 411 to communicate with the network element associated with the extracted network element address. This communication may include using an IDL-based messaging scheme to send, for example, messages 422 that comport with the CORBA protocol. For example, the request broker 411 may have a pre-compiled IDL instance (or adapter) associated with each of the network elements in the system. The request broker 411 may therefore retrieve the pre-compiled IDL from the IDL store 413 to instantiate a client with an IDL that is compatible with the target network element… In one example scenario, the request broker 411 may identify two or more remote procedure calls to perform using one or more precompiled IDL adapters in order to satisfy the request message 408.” The two or more remote procedure calls to perform to satisfy the request message correlates to a first process. The RPC manager using a request broker to instantiate a client and identify RPC calls to satisfy the request message correlates to a second process to provide an RPC interface for a first process)
Bodner does not explicitly teach that the second process is executed by a network interface device and that the method is in a data center. However, network interface devices are a popular method of executing RPC interfaces as evidenced by Keith (Paragraphs 61-62 and 95-96, “The system can include at least one device 216. The device 216 may be referred to as an intermediary device, an appliance, a data processing system, or a gRPC appliance, for example… The device 216 can include one or more of an interface 220, a detector 224, a message modifier 228, or a database 232… The interface 220 can include at least a built-in network adapter, network interface card, PCMCIA network card, EXPRESSCARD network card, card bus network adapter, wireless network adapter, USB network adapter, modem, or any other device suitable for interfacing one or more devices within the system 200 to any type of network capable of communication. The interface 220 can communicate with one or more aforementioned components to at least receive data from client devices 208 for processing and transmit data to at least the servers 240 to reduce the vulnerability and improve performance of the server 240… In further detail, a device (e.g., device 216) can receive a message from a client (e.g., client device) with various fields to execute one or more routines on the a network node (e.g., a server) remote from the client, at step 405. The device can be an intermediary between the client and the server. For example, the client can execute an application (e.g., web browser, email application, local application, virtual application, among others) to establish a communication channel to the server. The device can intercept and receive the message from the client transmitting the message via the application. The message can correspond to a gRPC protocol, where the client can be a gRPC client (e.g., RPC or gRPC based client), and the server can be a gRPC server (e.g., RPC or gRPC based server) … For example, the device can receive messages from clients, process the messages, and transmit the messages to servers.” The device including an interface with a built-in network interface card correlates to a network interface device. The device intercepting and processing the RPC message from the client before transmitting the message to the server correlates to a second process). Additionally, data centers are a popular type of computing environment as evidenced by Keith (Paragraph 35, “In embodiments, the computing environment 160 may provide client 165 with one or more resources provided by a network environment. The computing environment 160 may include one or more clients 165a-165n, in communication with a cloud 175 over one or more networks 170. Clients 165 may include, e.g., thick clients, thin clients, and zero clients. The cloud 108 may include back end platforms, e.g., servers, storage, server farms or data centers. The clients 165 can be the same as or substantially similar to computer 100 of FIG. 1A.” The cloud including data centers in communication with clients across a network environment correlate to the method being in a data center).
Bodner does not explicitly teach:
and allocating memory to share at least one RPC message as at least one formatted object among the first and second processes: and linearizing the at least one formatted object and storing the linearized at least one formatted object as a contiguous sequence of bytes in memory for access by the second process.
However, Keith teaches:
and allocating memory to share at least one RPC message as at least one formatted object among the first and second processes (Paragraphs 87-88 and 95-96, “The device can include a database 232. The database 232 can be referred to as a storage device, a data repository, or a memory. The database 232 can be physical storage volumes and virtual storage volumes or arrays thereof. The database 232 can include, store, or maintain information received from the client device 208. The database 232 can store information received from the server 240. For example, the database 232 can store messages received from the client device 208 to be transmitted to the server 240 or messages received from the server 240 for forwarding to the client device 208… The database 232 can store processed data from the message modifier 228… In further detail, a device (e.g., device 216) can receive a message from a client (e.g., client device) with various fields to execute one or more routines on the a network node (e.g., a server) remote from the client, at step 405. The device can be an intermediary between the client and the server. For example, the client can execute an application (e.g., web browser, email application, local application, virtual application, among others) to establish a communication channel to the server. The device can intercept and receive the message from the client transmitting the message via the application. The message can correspond to a gRPC protocol, where the client can be a gRPC client (e.g., RPC or gRPC based client), and the server can be a gRPC server (e.g., RPC or gRPC based server) … For example, the device can receive messages from clients, process the messages, and transmit the messages to servers.” The device including a database which includes, stores, or maintains information received from the client and server correlates to the memory allocation among the processes. The device intercepting and processing the RPC message from the client before transmitting the message to the server correlates to sharing at least one RPC message. The database storing processed data from the message modifier correlates to the at least one RPC message being a formatted object accessible from memory): and linearizing the at least one formatted object and storing the linearized at least one formatted object in memory for access by the second process (Paragraphs 69 and 87-88, “In some cases, when receiving a file (e.g., a proto file) from the server 240, the device 216 can compile the file into a document, such as a JSON document. The detector 224 can import the JSON document and arrange or store the JSON information (e.g., range of the values) in the database 232. The JSON information can be referred to as a memory representation of the file (e.g., a registry). The JSON information can be used as a runtime validator to ensure all fields are fully described in their definition file… The device can include a database 232. The database 232 can be referred to as a storage device, a data repository, or a memory. The database 232 can be physical storage volumes and virtual storage volumes or arrays thereof. The database 232 can include, store, or maintain information received from the client device 208. The database 232 can store information received from the server 240. For example, the database 232 can store messages received from the client device 208 to be transmitted to the server 240 or messages received from the server 240 for forwarding to the client device 208… The database 232 can include, store, or maintain other data described hereinabove, such as the categorization of each field of messages, proto files or configuration files of client devices 208 or servers 240, or stub libraries from the server 240.” The device compiling the proto file into a JSON document and storing the JSON information in the database correlates to the first process causing a network interface device to linearize at least one object and store the linearized at least one object into memory. The information stored in the database being transmitted between the client and server correlates to the object in memory being stored into memory for access by the second process).
Keith does not explicitly teach that the object [is stored] as a contiguous sequence of bytes in memory. However, storing objects as a contiguous sequence of bytes in memory is a popular method of storing objects for transfer to a second memory address space as evidenced by Demchenko (Paragraph 54, “In order to render the object susceptible for being transferred to the second memory address space 220, the object must first be serialized, i.e. represented as a contiguous sequence of bytes. According to implementations of the present technology, this is achieved by allocating a contiguous block of memory 216 sufficiently large to contain all of the data of the object, and then copying that data to the contiguous block of memory 216.” The object being serialized and stored in a contiguous block of memory correlates to storing objects as a contiguous sequence of bytes in memory).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with and allocating memory to share at least one RPC message as at least one formatted object among the first and second processes: and linearizing the at least one formatted object and storing the linearized at least one formatted object as a contiguous sequence of bytes in memory for access by the second process as taught by Keith because the database can include, store, or maintain information from connected devices as well as policy storage, which one or more components of the device can enforce. These policies can be used for processing messages to identify invalid, unknown, duplicate or undesired fields to mitigate potential attacks. Processing shared messages can reduce the vulnerability to the end or other network node, increase the performance of the server and improve latency of the node (Keith: paragraph 87-88 and 96).
Additionally, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with store the at least one object as a contiguous sequence of bytes in memory as taught by Demchenko because transferring objects to a second memory address space would require the object to be serialized or represented as a contiguous sequence of bytes. Then, transferring the object by copying the contiguous block of memory to a second memory address space preserves the integrity of any absolute references to memory addresses included in the object (Demchenko: paragraphs 54 and 56).
With regards to Claim 18, Bodner in view of Keith, Demchenko teaches the method of claim 17 above. Keith further teaches:
wherein the at least one formatted object comprises an object in one or more contiguous memory blocks (Paragraphs 69 and 87-88, “In some cases, when receiving a file (e.g., a proto file) from the server 240, the device 216 can compile the file into a document, such as a JSON document. The detector 224 can import the JSON document and arrange or store the JSON information (e.g., range of the values) in the database 232. The JSON information can be referred to as a memory representation of the file (e.g., a registry). The JSON information can be used as a runtime validator to ensure all fields are fully described in their definition file… The device can include a database 232. The database 232 can be referred to as a storage device, a data repository, or a memory. The database 232 can be physical storage volumes and virtual storage volumes or arrays thereof. The database 232 can include, store, or maintain information received from the client device 208. The database 232 can store information received from the server 240. For example, the database 232 can store messages received from the client device 208 to be transmitted to the server 240 or messages received from the server 240 for forwarding to the client device 208… The database 232 can include, store, or maintain other data described hereinabove, such as the categorization of each field of messages, proto files or configuration files of client devices 208 or servers 240, or stub libraries from the server 240… The database 232 can store processed data from the message modifier 228.” The device including a database which includes, stores, or maintains information received from the client and server such as proto or configuration files correlates to one or more contiguous memory blocks. The message which can be a proto file in JSON format being processed and stored in the database correlates to the at least one formatted object comprising a linearized object structure comprising an object in one or more contiguous memory blocks).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with wherein the at least one formatted object comprises an object in one or more contiguous memory blocks as taught by Keith because the database can include, store, or maintain information from connected devices as well as policy storage, which one or more components of the device can enforce. These policies can be used for processing messages to identify invalid, unknown, duplicate or undesired fields to mitigate potential attacks. Formatting shared messages through processing can reduce the vulnerability to the end or other network node, increase the performance of the server and improve latency of the node (Keith: paragraph 87-88 and 96).
With regards to Claim 18, Bodner in view of Keith and Demchenko teaches the method of claim 17 above. Keith further teaches:
storing the at least one linearized object as an object in one or more contiguous memory blocks (Paragraphs 69 and 87-88, “In some cases, when receiving a file (e.g., a proto file) from the server 240, the device 216 can compile the file into a document, such as a JSON document. The detector 224 can import the JSON document and arrange or store the JSON information (e.g., range of the values) in the database 232. The JSON information can be referred to as a memory representation of the file (e.g., a registry). The JSON information can be used as a runtime validator to ensure all fields are fully described in their definition file… The device can include a database 232. The database 232 can be referred to as a storage device, a data repository, or a memory. The database 232 can be physical storage volumes and virtual storage volumes or arrays thereof. The database 232 can include, store, or maintain information received from the client device 208. The database 232 can store information received from the server 240. For example, the database 232 can store messages received from the client device 208 to be transmitted to the server 240 or messages received from the server 240 for forwarding to the client device 208… The database 232 can include, store, or maintain other data described hereinabove, such as the categorization of each field of messages, proto files or configuration files of client devices 208 or servers 240, or stub libraries from the server 240.” The device including a database which includes, stores, or maintains information received from the client and server such as proto or configuration files correlates to one or more contiguous memory blocks. The message which can be a proto file in JSON format being stored in the database correlates to storing a linearized object comprising an object in one or more contiguous memory blocks).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with storing the at least one linearized object as an object in one or more contiguous memory blocks as taught by Keith because the database can include, store, or maintain information from connected devices as well as policy storage, which one or more components of the device can enforce. These policies can be used for processing messages to identify invalid, unknown, duplicate or undesired fields to mitigate potential attacks (Keith: paragraph 87-88).
Claim(s) 20 are rejected under 35 U.S.C. 103 as being unpatentable over Bodner in view of Keith and Takeda.
With regards to Claim 20, Bodner in view of Keith and Demchenko teaches the method of claim 18 above. Bodner in view of Keith does not explicitly teach:
wherein the second process provides a RPC interface for the first process by utilizing one or more accelerator devices that perform one or more of: data transformation, encryption, reliable transport, load balancing, traffic routing, secure key storage, authentication, and/or observability.
However, Takeda teaches:
wherein the second process provides a RPC interface for the first process by utilizing one or more accelerator devices that perform one or more of: data transformation, encryption, reliable transport, load balancing, traffic routing, secure key storage, authentication, and/or observability (Paragraph 53, “The RPC library 223 is a library used for the RPC. In the RPC library 223, an RPC server 2231 and a reexecution RPC server 2232 are generated by the code generator 155 of the host PC 10. Upon receipt of a function process request issued by the RPC client 1541, the RPC server 2231 performs the function process. The function can offload the process onto the hardware accelerator, the DSP and the like, by calling the image processing library 222.” The RPC server performing the function process which offloads the process onto the hardware accelerator correlates to the second process utilizing one or more accelerator devices to perform one or more of load balancing).
Therefore, it would have been obvious to one of ordinary skill in the art to which said subject matter pertains before the effective filing date of the claimed invention to combine Bodner with wherein the second process provides a RPC interface for the first process by utilizing one or more accelerator devices that perform one or more of: data transformation, encryption, reliable transport, load balancing, traffic routing, secure key storage, authentication, and/or observability as taught by Takeda because the performance of a pipeline-parallelized application can be more correctly estimated using an accelerator by profiling resource contention. The profiled resource contention can be used to group RPC nodes to reduce idle time and increase utilization of worker threads (Takeda: paragraphs 128-131).
Prior Art Made of Record
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
Jordahl et al. (U.S. Patent No. US 20140040924 A1); teaching a method of invoking additional processing at a remote computing device using RPCs. A list of functions supposed by the remote computing device is received from the remote computing device, where a function that requires metadata is identified. The metadata and arguments required by the function is accessed and an RPC message based on the function is transmitted to the remote computing device. The RPC message invokes additional processing based on the provided metadata, which can be provided as an object stored on the server device.
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 SELINA HU whose telephone number is (571)272-5428. The examiner can normally be reached Monday-Friday 8:30-5:30.
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, Chat Do can be reached at (571) 272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
The publicPAIR and privatePAIR systems are no longer available. 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.
/SELINA ELISA HU/ Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
Prosecution Insights