DETAILED ACTION
Claims 1-20 are pending in this application.
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 .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 2, -9, 13-16, 19 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2004/0244012 A1 to Massarenti in view of U.S. Pub. No. 2019/0042290 A1 to Bailey et al. and in further view of U.S. Pat. No. 6,928.488 B1 issued to de Jong et al. and further in view of U.S. Pub. No. 2022/0114270 A1 to Wang et al.
As to claim 1, Massarenti teaches a computer-implementable method for encoded byte message serialization and deserialization by microservices comprising:
receiving a multi-level message with generic data types (Signature Table Data Structure 212) for serialization (Serialization 206) and deserialization (DeSerialization 206) the encoded byte message, wherein the multi-level message includes a top level message as to type that provides general information about content (Predecessor Object Type 302'/Graph Of Objects 204) and applicability, and sub-messages as to types that include content related to purpose which includes an undefined type that contains properties related to schema (Signature Table Data Structure 212) for serialization and deserialization of the encoded byte message (Successor Reference 306S(1)/Graph Of Objects 204);
processing content of top level message (Predecessor Object Type 302'/Graph Of Objects 204) and sub-messages (Successor Reference 306S(1)/Graph Of Objects 204) to determine the undefined type that contains properties related to schema for serialization and deserialization of the encoded byte message (Blocks 702/802) (“…At block 702, a type system is consulted to acquire an object type. For example, a type system 208 may be consulted to acquire an object type 302. At block 704, a type name for the acquired object type is extracted. For example, a type name 304 may be extracted from object type 302…At block 706, value and reference fields are extracted for the acquired object type. For example, value field(s) 306V and reference field(s) 306R may be extracted from object type 302. At block 708, extractions (e.g., for type name and/or fields) are repeated recursively for referenced predecessor object type(s). For example, for a predecessor reference field 306RP that references another object type 302', the type name 304' and/or fields 306' are extracted for that predecessor object type 302' in a recursive manner, which therefore continues for parent(s) of that predecessor object type 302' (if any)… At block 802, a root of a graph to be serialized is added to a list of nodes to be processed. For example, a graph of objects 204 may be accepted for processing, and a node for an object 502 that has no predecessor references (e.g., object #3 502(3)) may be selected as the root node and added to a list of objects for serialization processing. Such a list of objects for serialization processing may be formed from objects 502 in graph of objects 204. It should be noted that a root node may be more generally considered as any node at which serialization processing commences…” paragraphs 0070/0071/0079); and
loading the schema properties of the sub-messages (graph), of the undefined type for serialization and deserialization of the encoded byte message (Blocks 704/706) (“…At block 702, a type system is consulted to acquire an object type. For example, a type system 208 may be consulted to acquire an object type 302. At block 704, a type name for the acquired object type is extracted. For example, a type name 304 may be extracted from object type 302…At block 706, value and reference fields are extracted for the acquired object type. For example, value field(s) 306V and reference field(s) 306R may be extracted from object type 302. At block 708, extractions (e.g., for type name and/or fields) are repeated recursively for referenced predecessor object type(s). For example, for a predecessor reference field 306RP that references another object type 302', the type name 304' and/or fields 306' are extracted for that predecessor object type 302' in a recursive manner, which therefore continues for parent(s) of that predecessor object type 302' (if any)… At block 802, a root of a graph to be serialized is added to a list of nodes to be processed. For example, a graph of objects 204 may be accepted for processing, and a node for an object 502 that has no predecessor references (e.g., object #3 502(3)) may be selected as the root node and added to a list of objects for serialization processing. Such a list of objects for serialization processing may be formed from objects 502 in graph of objects 204. It should be noted that a root node may be more generally considered as any node at which serialization processing commences…” paragraphs 0070/0071/0079).
Massarenti is silent with reference to dynamically loading the schema properties of the data type for serialization and deserialization for consumption by the microservices,
wherein the sub-messages are used for the encoded byte message transfer and include schema properties and
wherein schema metadata is received to generate declarations to allow for serialization of the messages wherein the declarations are used to serialize the messages.
Bailey teaches dynamically (automatically) loading the schema properties of the undefined type for serialization and deserialization for consumption by the microservices (FastScore;) (“…The input and output schemas have been specified in smart comments at the beginning of the model; [0469] The score method has been renamed to action, and all JSON deserialization and serialization of the input and output records is taken care of automatically by FastScore;…Input and Output Schemas…FastScore may use AVRO schemas to enforce type and/or data science validation on model inputs and outputs. Both input/output streams, as well as the models themselves, should specify schemas…The input schema for data may support complexity if the input records contain many fields…” paragraphs 0468/0469/0472/0473).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Massarenti with the teaching of Bailey because the teaching of Bailey would improve the system of Massarenti by providing a FastScore for automatically inputting schema information for deserialization and serialization as needed.
de Jong teaches wherein the sub-messages (graph of objects) are used for the encoded byte message transfer and include schema properties (plurality of serialization rules) (“…FIG. 6 illustrates one particular methodology for serialization of a graph of objects into a serialization stream in accordance with one aspect of the present invention. The methodology begins at 200 where serialization is invoked to serialize a graph of objects. At 210, an object is retrieved from an object graph. At 220, the method determines if the object has been seen before. If the object has been seen before (YES), the method proceeds to 230. If the method has not been seen before (NO), the method advances to 225 where the object is assigned an object ID. At 230, the methodology determines the serialization rules for the object based on the object's type from a plurality of serialization rules. For example, the serialization rules can be defined in the object by implementing a serializable interface and defining the serialization information that will be provided. Alternatively, a surrogate or third party object can be provided that defines the serialization information that will be provided for objects of a given type. Finally, a default serialization may be employed if the object is marked with serializable attributes but does not have a surrogate or implement a serializable interface. The serialization rules may restrict object information from being serialized, specify a different object type to be serialized or specify that the object is a remote object type and provide serialization information accordingly…At 240, the object is pushed to a data structure based on the defined serialization rules. At 250, the methodology determines if the object is the last object of the graph. If the object is not the last object of the graph (NO), the methodology returns to 210 to get the next object of the graph. If the object is the last object of the graph (YES), the methodology proceeds to step 260. At 260, the graph is serialized to an externalized format defined by the pluggable formatter. The serialization routine then is completed at 270…” Col. 14 Ln. 10-42).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Massarenti and Bailey with the teaching of de Jong because the teaching of de Jong would improve the system of Massarenti and Bailey by providing a user definable rule data set for serializing and deserializing graph of messages.
Wang teaches wherein schema metadata is received to generate declarations to allow for serialization of the messages wherein the declarations are used to serialize the messages (descriptor formats/Protobuf-schema) (“…As an example, Protocol Buffers (Protobuf) is a language neutral, platform-neutral mechanism to serialize structured data into byte streams and deserialize byte streams back to structured data...FIG. 17 depicts an example of descriptor formats. The example descriptor formats are shown for serialization, de-serialization or batch descriptor processing… FIG. 18 depicts an example of serialization. For example, to transform a message from a first format to a second format, software can generate the transformation map with corresponding field, type, address per field and sub-objects. The accelerator can serialize the object (e.g., Protobuf-schema) to the corresponding field, type, address…Schema can define the messages with fields and their corresponding types. A compiler can receive the scheme and generates code for a specific programming language (e.g., C++, Python, etc.) The accelerator receives a representation (Map) of message structure and the accelerator processing pipelines perform parallel processing across fields based on the Map. A Map can identify Field ID, type, memory address, and address offsets of fields. Field-ID can identify a field, input for the accelerator to create serialized string. Type can represent a data type, input for the accelerator to create serialized string. Address can represent a memory location where the value located. Output Offset can indicate a corresponding offset in the output buffer for this field…Transformation map can configure the multiple compute engines in the accelerator to read the field and write the output for the field in parallel without any dependency among fields. The accelerator can perform parallel processing of fields based on the address offset of the fields and Map. A compute engine can use shifters to serialize the messages into byte streams and write back to the pre-allocated memory space for software to access. Examples of protobuf-schema are shown, but any type of schema can be used…In serialization transformation map, Field 1 refers to message type uint 64. Field 2 refers to a message type string. Field 3 can refer to a repeat message type. Other field identifiers are shown. Address can refer to an address (e.g., virtual or physical) in system memory that stores data. Output offset can refer to results of serialization. Output results can be written in parallel to memory. Use of transformation map allows parallelization of processing of messages…FIG. 19 depicts an example of deserialization. Deserialization can transform received byte streams from to message objects that the software can process. A process that requests performance of the workload by the offload circuitry can provide a message schema in the form of a deserialization transformation map to indicate the structure of the message the byte stream represents. Based on the field ID and type, the accelerator device can allocate a staging buffer with a certain default size. The accelerator can process the received byte streams with pipelining that deserializes fields in parallel…A deserialization transformation map can be used to transform a serialized string into a de-serialized object. The deserialization transformation map can include Field-ID, Type, Map offset, count (cnt), and default. Field-ID can represent an input for the accelerator to perform deserialization operation. Type can represent a data type for the accelerator to perform deserialization operation. For a nested data type, map offset and count (cnt) can be used to inputs for sub-fields. Default can represent a default value for the fields not presented in the serialized string…Transformation map can allow the accelerator to lookup the first level (root) schema with the field-id directly. Transformation map can enable the multiple compute engines in the accelerator to read the field and write the output for the field in parallel without any dependency among fields. Root fields (1, 2, 3, and 4) are listed first, then for the field(s) who has the next level of (sub)fields (e.g., 3-1 and 3-2), sub-fields will be listed following the last root field. In the Map Offset column, the transformation map informs the deserialization engine that the field #3 has 2 sub-fields and they start from offset 5 (e.g., 5.sup.th row). In other examples, a transformation map can sequentially list the fields with no offset indication. Other formats of transformation maps can be used…A serialization or de-serialization transformation map can be provided per data transformation code generation. The transformation map can be specific to a message definition. The process that requests a serialization or de-serialization can submit a deserialization descriptor with the pointer to the transformation map, an input serialized string to be de-serialized to a message, other necessary information for the descriptor. The offload engine parses the descriptor and use the information (serialized string, transformation map, input, etc.) to deserialize the input and create a message…” paragraphs 0080/0096-0104).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Massarenti, Bailey and de Jong with the teaching of Wang because the teaching of Wang would improve the system of Massarenti, Bailey and de Jong by providing a structure of a database that refers to organization of data as a blueprint of how the database is constructed and should accessed.
As to claim 2, Wang teaches the method of claim 1, wherein the microservices are written in Python, Java, C#.NET, Golang, Scala, or C++ (specific programming language (e.g., C++, Python, etc.)) (“…Schema can define the messages with fields and their corresponding types. A compiler can receive the scheme and generates code for a specific programming language (e.g., C++, Python, etc.) The accelerator receives a representation (Map) of message structure and the accelerator processing pipelines perform parallel processing across fields based on the Map. A Map can identify Field ID, type, memory address, and address offsets of fields. Field-ID can identify a field, input for the accelerator to create serialized string. Type can represent a data type, input for the accelerator to create serialized string. Address can represent a memory location where the value located. Output Offset can indicate a corresponding offset in the output buffer for this field. …” paragraph 0018).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Massarenti, Bailley, and de Jong with the teaching of Wang because the teaching of Wang would improve the system of Massarenti, Bailley, de Jong and Kathuria Massarenti, Bailley, and de Jong by providing a high level object oriented programming based on objects and software entities that encapsulate data and functions to keep internal details of an object hidden from outside code and consuming code can only interact with an object via its public members, due to a language providing access modifiers that control visibility.
As to claim 6, Massarenti teaches the method of claim 1, wherein a sub-message references or embeds a message as to types that include content related to purpose which includes an undefined type that contains properties related to schema for serialization and deserialization of the encoded byte message (“… FIG. 5 is an exemplary graph of objects 204 as shown in FIG. 2. Graph of objects 204 includes "n" nodes or objects 502, where n=1, 2, 3 . . . up to the number of objects currently instantiated and/or being manipulated. Four objects are illustrated (n=4). Specifically, object #1 502(1), object #2 502(2), object #3 502(3), and object #n 502(n) are included as part of graph of objects 204…Graph of objects 204 also includes items representing various fields, both value and reference fields, of objects 502(1 . . . n). A value field is represented for each of the four objects #I-n 502(1 . . . n). Although only one value field is included for each object 502 in FIG. 5, each object 502 may in practice have multiple such value fields…The reference fields represent linkages between and among different objects 502, and they include both predecessor and successor references. Each of objects #1, #2, #n 502(1, 2, n) includes a predecessor reference field as represented by the predecessor reference arrows. Specifically, object #1 502(1) and object #2 502(2) each reference object #3 502(3) as their predecessor object. Object #n 502(n) references object #2 502(2) as its predecessor object…” paragraphs 0057-0059).
As to claim 7, Massarenti teaches the method of claim 1, wherein a key is used to look up the messages as to types that include content related to purpose which includes an undefined type that contains properties related to schema for serialization and deserialization of the encoded byte message (“…At block 802, a root of a graph to be serialized is added to a list of nodes to be processed. For example, a graph of objects 204 may be accepted for processing, and a node for an object 502 that has no predecessor references (e.g., object #3 502(3)) may be selected as the root node and added to a list of objects for serialization processing. Such a list of objects for serialization processing may be formed from objects 502 in graph of objects 204. It should be noted that a root node may be more generally considered as any node at which serialization processing commences…At block 804, it is determined whether there are more nodes in the list to process. For example, it may be determined whether there are more objects 502 of graph of objects 204 that have yet to be serialized. If so, flow continues at block 806 in which the next node from the list of nodes to be processed is extracted. For example, a next object 502 may be extracted from the list of objects…” paragraphs 0079/0080).
As to claims 8 and 15, see the rejection of claim 1 above, expect for a processor, a data bus and a non-transitory, computer-readable storage medium.
Massarenti teaches a processor (Processing Unit 100), a data bus (System Bus 1008) and a non-transitory, computer-readable storage medium (Hard Disk 1016).
As to claims 9 and 16, see the rejection of claim 2 above.
As to claims 13 and 19, see the rejection of claim 6 above.
As to claims 14 and 20, see the rejection of claim 7 above.
Claims 3-4, 10-11, and 17-18 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2004/0244012 A1 to Massarenti in view of U.S. Pub. No. 2019/0042290 A1 to Bailey et al. and in further view of U.S. Pat. No. 6,928.488 B1 issued to de Jong et al. and further in view of U.S. Pub. No. 2022/0114270 A1 to Wang et al. as applied to claims 1, 8 and 15 above, and further in view of U.S. Pub. No. 2018/0332367 A1 to Kaitchuck et al.
As to claim 3, Massarenti as modified Bailey, de Jong and Wang teaches the teaches the method of claim 2, however it is silent with reference to wherein the microservices are one of Kafka, Pravega or Pulsar.
Kaitchuck teaches wherein the microservices are one of Kafka, Pravega or Pulsar (Pravega) (“…In many implementations, a primitive data element in Pravega may be an Event. In some implementations, an Event may be a collection of bytes within a Stream. In certain implementations, an Event may be as simple as a small number of bytes containing a temperature reading from an IoT sensor composed of a timestamp, a metric identifier and a value. In some implementations, an event may be web data associated with a user click on a website. In certain implementations, an event may be anything you can represent as a collection of bytes. In many implementations, applications may make sense of Events using standard Java serializers and deserializers, allowing them to read and write objects in Pravega using similar techniques to reading and writing objects from file-based storage…” paragraph 0018).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Massarenti, Bailley, de Jong and Wang with the teaching of Kaitchuck because the teaching of Kaitchuck would improve the system of Massarenti, Bailley, de Jong and Wang by providing an open source distributed storage service implementing streams.
As to claim 4, Massarenti as modified by Bailey, de Jong and Wang teaches the method of claim 1, however it is silent with reference to wherein the encoded byte message are sent as Kafka, Pulsar or Pravega messages.
Kaitchuck teaches wherein the encoded byte message are sent as Kafka, Pulsar or Pravega messages (Pravega) (“…In many implementations, a primitive data element in Pravega may be an Event. In some implementations, an Event may be a collection of bytes within a Stream. In certain implementations, an Event may be as simple as a small number of bytes containing a temperature reading from an IoT sensor composed of a timestamp, a metric identifier and a value. In some implementations, an event may be web data associated with a user click on a website. In certain implementations, an event may be anything you can represent as a collection of bytes. In many implementations, applications may make sense of Events using standard Java serializers and deserializers, allowing them to read and write objects in Pravega using similar techniques to reading and writing objects from file-based storage…” paragraph 0018).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Massarenti, Bailley, de Jong and Wang with the teaching of Kaitchuck because the teaching of Kaitchuck would improve the system of Massarenti, Bailley, de Jong and Wang by providing an open source distributed storage service implementing streams.
As to claims 10 and 17, see the rejection of claim 3 above.
As to claims 11 and 18, see the rejection of claim 4 above.
Claims 5 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2004/0244012 A1 to Massarenti in view of U.S. Pub. No. 2019/0042290 A1 to Bailey et al. and in further view of U.S. Pat. No. 6,928.488 B1 issued to de Jong et al. and further in view of U.S. Pub. No. 2022/0114270 A1 to Wang et al. as applied to claims 1 and 8 above, and further in view of U.S. Pub. No. 2022/0311835 A1 to Aluvila.
As to claim 5, Massarenti as modified Bailey, de Jong and Wang teaches the method of claim 1, wherein the multi-level message is formatted as per one of Google Protocol Buffers Avro Serialization Framework, Thrift Serialization Protocol.
Aluvila teaches wherein the multi-level message is formatted as per one of Google Protocol Buffers, Avro Serialization Framework, Thrift Serialization Protocol (Google Protocol Buffers) (“…Messages to be sent via an IPC mechanism may be serialized prior to transport. Likewise, messages received at a client end service may be deserialized. In the embodiment illustrated in FIG. 2, the IPC management layer 220 serializes messages prior to transport and deserializes received messages. The IPC management layer 220 may access a message serialization/deserialization layer 225 to perform message serialization/deserialization. In embodiments of the present disclosure, message serialization/deserialization is performed using a format that is independent of the IPC mechanism used for the transport of the messages. Embodiments described herein perform serialization/deserialization using Google Protocol Buffers however other serialization/deserialization formats that are known in the art may be used as alternatives…Alternatively, message serialization may be performed by the server-side service prior to providing the message to the IPC management layer 220. Likewise, the client-side service may de-serialize a message after the client has received the message from the IPC management layer 220. In embodiments where message serialization/deserialization is performed by the services themselves, the format used may also be independent of the IPC mechanism used to transport the messages. For example, Google Protocol Buffers may be used to serialize/deserialize messages by the services…” paragraphs 0052/0053).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Massarenti, Bailley, de Jong and Wang with the teaching of Aluvila because the teaching of Aluvila would improve the system of Massarenti, Bailley, de Jong and Wang by providing an open-source cross-platform data format used to serialize structured data.
As to claim 12, see the rejection of claim 5 above.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection relies on additional reference not applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES E ANYA whose telephone number is (571)272-3757. The examiner can normally be reached Mon-Fir. 9-6pm.
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, KEVIN YOUNG can be reached at 571-270-3180. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHARLES E ANYA/Primary Examiner, Art Unit 2194