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 communication filed on 03/28/2025. Claims 32-51 have been examined. Claims 1-31 are cancelled.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 08/26/2025 .The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner..
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 1-47 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-29 of Patent No. US 12,101,388 in view of He.
Claims 48-51 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-29 of Patent No. US 12,101,388.
Although the conflicting claims are not identical, they are not patentably distinct from each other because:
See Below for analysis
Claims 32-51 of Instant application
Claims 1-29 of Patent No. 12,101,388
Claims 32,47
A method/system comprising:
creating a normalized binary specification model, including:
receiving one or more existing binary descriptions, wherein each existing binary description is a document that describes aspects of a respective binary communication protocol, binary data storage format, or binary data processing architecture;
identifying a description type of each of the one or more existing binary descriptions; and
assigning, based on the description type, each of the one more existing binary descriptions to a respective loader from a plurality of loaders,
wherein each loader of the plurality of loaders is configured to create and output, based on the one or more existing binary descriptions, a normalized binary description..
Claim 1
A method/system
A method comprising:
creating a normalized binary specification model, including:
receiving existing binary descriptions corresponding to documents that describe aspects of respective binary communication protocols, binary data storage formats, or binary data processing architectures;
identifying description type of each of the existing binary descriptions; based on the description type, assign each of the existing binary descriptions to a respective loader from a plurality of loaders; wherein each loader from the plurality of loaders performs the following steps: ingesting corresponding one or more descriptions from the existing binary descriptions; discerning relevant binary information items from within the corresponding one or more descriptions; converting the relevant binary information items into normalized binary specification components, wherein the normalized binary specification components include: (a) normalized binary specification types, (b) normalized binary specification groups, (c) normalized binary specification rules, (d) normalized binary specification values, and (e) normalized binary specification actions; generating identifiers and assigning a respective identifier to each of the normalized binary specification components to produce identified normalized binary specification components; and creating a respective ordered list for each of the normalized binary specification components.
Claim 33
wherein identifying the description type includes: identifying the relevant binary information items within each of the one or more existing binary descriptions and comparing the relevant binary information items within the one or more existing binary descriptions to known binary description formats; and assigning, based on the comparison, a description type to each of the one or more existing binary descriptions.
Claim 2
wherein the identifying the description type includes: identifying the relevant binary information items within each of the existing binary descriptions and comparing the relevant binary information items within the existing binary descriptions to known description formats; based on the comparison, assign a description type to each of the existing binary descriptions..
Claim 34
wherein each loader from the plurality of loaders performs the following step:
ingesting corresponding one or more binary descriptions from the one or more existing binary descriptions.
Claim 1
wherein each loader from the plurality of loaders performs the following steps: ingesting corresponding one or more descriptions from the existing binary descriptions;
Claim 35
wherein each loader from the plurality of loaders performs the following step:
discerning relevant binary information items from within the corresponding one or more binary descriptions..
Claim 1
…wherein each loader from the plurality of loaders performs the following steps:…; discerning relevant binary information items from within the corresponding one or more descriptions
Claim 36
wherein each loader from the plurality of loaders performs the following step:
converting the relevant binary information items into normalized binary specification components.
Claim 1
wherein each loader from the plurality of loaders performs the following steps:….; converting the relevant binary information items into normalized binary specification components,.
Claims 37
wherein the normalized binary specification components include:(a) normalized binary specification types,(b) normalized binary specification groups,(c) normalized binary specification rules,(d) normalized binary specification values, and(e) normalized binary specification actions;
Claim 1
wherein the normalized binary specification components include: (a) normalized binary specification types, (b) normalized binary specification groups, (c) normalized binary specification rules, (d) normalized binary specification values, and (e) normalized binary specification actions;
Claim 38
wherein each loader from the plurality of loaders performs the following steps:
generating identifiers and assigning a respective identifier to each of the normalized binary specification components to produce identified normalized binary specification components; and creating a respective ordered list for each of the normalized binary specification components.
Claim 1
wherein each loader from the plurality of loaders performs the following steps ….generating identifiers and assigning a respective identifier to each of the normalized binary specification components to produce identified normalized binary specification components;. and creating a respective ordered list for each of the normalized binary specification components.
Claims 39,49
wherein the converting includes: normalizing semantics of names in the relevant binary information items into names of the normalized binary specification components.
Claims 3 ,13
wherein the converting includes: normalizing semantics of names in the relevant binary information items into names of the normalized binary specification components..
Claims 40 ,50
wherein the converting includes: deconstructing binary information items describing binary types into normalized binary specification types consisting of lists of elementary binary type traits.
Claims 4,14
wherein the converting includes: deconstructing binary types of existing elementary binary components into lists of elementary type traits.
Claims 41,51
wherein the converting includes:
deconstructing binary information items describing binary rules into normalized binary specification rules consisting of lists of elementary binary rule parameters..
Claims 5,15
wherein the converting includes: deconstructing binary rules of existing elementary binary components into lists of ordered extensible parameters.
Claim 42
wherein the normalized binary specification components include:(f) extensile binary specification details including organization, version, date, and active/inactive status.
Claim 6
wherein the normalized binary specification components include: (f) details including organization, version, date, and active/inactive status.
Claim 43
wherein the generating identifiers includes :obtaining information from the normalized binary specification components; and generating the unique identifiers from the obtained information.
Claim 44
wherein the generating identifiers includes
:obtaining information from the normalized binary specification components;
generating a first iteration of identifiers from the obtained information; and
checking whether each of the identifiers in the first iteration is unique and, if not, generating a second iteration of identifiers in which the non-unique identifiers from the first iteration are made more complex.
Claim 7
wherein the generating identifiers includes: obtaining information from the normalized binary specification components; and generating the identifiers from the obtained information.
Claim 8
wherein the generating identifiers includes: obtaining information from the normalized binary specification components; generating a first iteration of identifiers from the obtained information; checking whether each of the identifiers in the first iteration is unique and, if not, generating a second iteration of identifiers in which the non-unique identifiers from the first iteration are made more complex.
Claim 45
providing a domain specific normalized binary specification editing language for a user to edit content of the identified normalized binary specification components.
Claim 9
providing a domain specific normalized binary specification editing language for a user to edit content of the identified normalized binary specification components.
Claim 46
providing a domain specific normalized binary specification editing language for a user to edit content of the identified normalized binary specification components, wherein the domain specific normalized binary specification editing language searches for the binary specification component identifiers and changes binary specification component information.
Claim 10
providing a domain specific normalized binary specification editing language for a user to edit content of the identified normalized binary specification components, wherein the domain specific normalized binary specification editing language searches for the identifiers and changes component information.
Claim 48
A method comprising:
creating a normalized binary specification model, including:
receiving one or more existing binary descriptions, each of the one or more existing binary descriptions describing at least one of a binary communication protocol, a binary data storage format, or a binary data processing architecture;
discerning relevant binary information items from within the one or more existing binary descriptions;
converting the relevant binary information items into normalized binary specification components;
generating identifiers and assigning a respective identifier to each of the normalized binary specification components to produce identified normalized binary specification components; and creating a respective ordered list for each of the identified normalized binary specification components.
Claim 1
A method comprising:
creating a normalized binary specification model, including:
receiving existing binary descriptions corresponding to documents that describe aspects of respective binary communication protocols, binary data storage formats, or binary data processing architectures;
identifying description type of each of the existing binary descriptions; based on the description type, assign each of the existing binary descriptions to a respective loader from a plurality of loaders; wherein each loader from the plurality of loaders performs the following steps: ingesting corresponding one or more descriptions from the existing binary descriptions; discerning relevant binary information items from within the corresponding one or more descriptions; converting the relevant binary information items into normalized binary specification components, wherein the normalized binary specification components include: (a) normalized binary specification types, (b) normalized binary specification groups, (c) normalized binary specification rules, (d) normalized binary specification values, and (e) normalized binary specification actions; generating identifiers and assigning a respective identifier to each of the normalized binary specification components to produce identified normalized binary specification components; and creating a respective ordered list for each of the normalized binary specification components.
With regards to claim 32,47, the Patent No. US 12,101,388 does not explicitly teach create and output, based on the one or more existing binary descriptions, a normalized binary description.. He teaches create and output, based on the one or more existing binary descriptions, a normalized binary( ¶ 0024, ¶0084-¶0085, ¶0102 -¶0103).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of Patent No. 12,101,388 to include the teachings of He. The motivation for doing so is to allow the system to provide a communication protocol conversion based on cross language data ( He – ¶ 0019).
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 32-36,38,40-41,43,47-48,50-51 are rejected under 35 U.S.C. 102(a1) as being anticipated by He et al. Publication No. CN 105337968 A (He hereinafter)
Regarding claim 32,
He teaches a method comprising:
creating a normalized binary specification model, including: receiving one or more existing binary descriptions, wherein each existing binary description is a document that describes aspects of a respective binary communication protocol, binary data storage format, or binary data processing architecture (Abstract - a conversion method for cross-platform communication protocol code, comprising the following steps: defining a binary data based on communication protocol, the communication protocol comprising a protocol head and data entity. said protocol head for storing the length and the communication protocol of the data entity of the protocol signaling, according to communication protocol conversion, comprises the communication protocol content description file, determining the communication protocol needs to be converted into the language type of the content of the description file format conversion - ¶0023 – Prepare a description file containing the contents of the universal communication protocol).
identifying a description type of each of the one or more existing binary descriptions (¶ 0024 - Determine the language type that the communication protocol needs to be converted into, and perform format conversion on the content of the description file); and
assigning, based on the description type, each of the one more existing binary descriptions to a respective loader from a plurality of loaders , wherein each loader of the plurality of loaders is configured to create and output, based on the one or more existing binary descriptions, a normalized binary description (¶ 0024 - Determine the language type that the communication protocol needs to be converted into, and perform format conversion on the content of the description file - ¶ 0025 - Generate and call the communication protocol interface file - ¶ 0084 – ¶0085 - determine the language type that the communication protocol needs to be converted into, that is, the language platform it will be used for, perform format conversion on the content of the description file, and convert it into a protocol suitable for the platform of the language type to be used - the available communication protocol interface file is generated and the communication protocol interface file can be called – ¶ 0102 – ¶ 0103 - The above steps are explained respectively. For example, the data type is described according to the cross language fixed- Length data type definition, as shown in Table 1 below. The fixed- Length data types of the data types corresponding to different languages have different expressions. According to the XML description file and the corresponding language platform, can be converted accordingly).
Regarding claim 33,
He further teaches
wherein identifying the description type includes: identifying the relevant binary information items within each of the one or more existing binary descriptions and comparing the relevant binary information items within the one or more existing binary descriptions to known binary description formats; and assigning, based on the comparison, a description type to each of the one or more existing binary descriptions (¶ 0112 - ¶0115 Determine the language type that the communication protocol needs to be converted into, and perform format conversion on the content of the description file; the methods and steps include the following: obtain the data type from the description language and determine the language type that the communication protocol needs to be converted into - According to the data type in the description file and the data type to be converted, the characteristic data conversion method is called to realize the conversion of the characteristic data. The above method can be used to perform format conversion by writing tools for converting specific language data types and byte arrays to each other -See Also ¶ 0124).
Regarding claim 34,
He further teaches
wherein each loader from the plurality of loaders performs the following step: ingesting corresponding one or more binary descriptions from the one or more existing binary descriptions(¶ 0029 - The description file includes data types, data objects, request interfaces, and callback interfaces See ¶ 0088-¶0089 - The description file is defined in XML format. The XML description file includes: data type, data object, request interface, and callback interface. Basic data types include: boolean, int, long, string, list, etc.; the data object is a combination of data in the description file; the data interface is used to request the method name of the server and the parameters that need to be passed in; the callback interface is used to Return the obtained data to the server).
Regarding claim 35,
He further teaches
wherein each loader from the plurality of loaders performs the following step: discerning relevant binary information items from within the corresponding one or more binary descriptions (¶ 0029 - The description file includes data types, data objects, request interfaces, and callback interfaces -See ¶ 0088-¶0089 - The description file is defined in XML format. The XML description file includes: data type, data object, request interface, and callback interface. Basic data types include: boolean, int, long, string, list, etc.; the data object is a combination of data in the description file; the data interface is used to request the method name of the server and the parameters that need to be passed in; the callback interface is used to Return the obtained data to the server).
Regarding claim 36,
He further teaches
wherein each loader from the plurality of loaders performs the following step: converting the relevant binary information items into normalized binary specification components (¶ 0051 – The protocol conversion module is used to obtain the data type from the description language and determine the language type that the general communication protocol needs to be converted into).
Regarding claim 38,
He further teaches
wherein each loader from the plurality of loaders performs the following steps: generating identifiers and assigning a respective identifier to each of the normalized binary specification components to produce identified normalized binary specification components; and creating a respective ordered list for each of the normalized binary specification components (¶ 0088 – ¶ 0104 - The description file is defined in XML format. The X ML description file includes: data type, data object, request interface, and callback interface. Basic data types include: boolean, int, long, string, list, etc.; the data object isa combination of data in the description file; the data interface is used to request the method name of the server and the parameters that need to be passed in; the callback interface is used to Return the obtained data to the server. For example, for ID type conversion, sending and feedback are implemented through the data interface and callback interface: The request interface can be: Send Message(String from ID ,String to ID ,String message). The Cali back interface can be: Send Message success( String from ID ,String to ID, intmessagel D) – ¶ 0105 – ¶ 0112 - For example, to determine that the root node tag name of the XML file is Chat Server, set the root node name through < protocol name= "Chat Server">; Define the structure of the communication protocol under the root node: define the structure through < struct name="Group info"></struct>, and the structure name is Group info . Define al I request method sets of the communication protocol under the root node: < request> </request> defines al I request method sets under the root node; Define all callback method sets of the communication protocol under the root node: <callback></callback> under the root node defines all callback method sets);
Regarding claim 40
He further teaches
wherein the converting includes: deconstructing binary information items describing binary types into normalized binary specification types consisting of lists of elementary binary type traits(¶ 0088 – ¶ 0104 - The description file is defined in XML format. The X ML description file includes: data type, data object, request interface, and callback interface. Basic data types include: boolean, int, long, string, list, etc.; the data object isa combination of data in the description file; the data interface is used to request the method name of the server and the parameters that need to be passed in; the callback interface is used to Return the obtained data to the server. For example, for ID type conversion, sending and feedback are implemented through the data interface and callback interface: The request interface can be: Send Message(String from ID ,String to ID ,String message). The Cali back interface can be: Send Message success( String from ID ,String to ID, int message ID) – ¶ 0105 – ¶ 0112 - For example, to determine that the root node tag name of the XML file is Chat Server, set the root node name through < protocol name= "Chat Server">; Define the structure of the communication protocol under the root node: define the structure through < struct name="Group info"></struct>, and the structure name is Group info . Define al I request method sets of the communication protocol under the root node: < request> </request> defines al I request method sets under the root node; Define all callback method sets of the communication protocol under the root node: <callback></callback> under the root node defines all callback method sets);
Regarding claim 41
He further teaches
wherein the converting includes: deconstructing binary information items describing binary rules into normalized binary specification rules consisting of lists of elementary binary rule parameters (¶ 00115-¶0117 The above method can be used to perform format conversion by writing tools for converting specific language data types and byte arrays to each other. For example: The conversion method between string and byte array in Java is as follows (1:). Convert string to byte array: Directly Cal the get Bytes() method of byte data to return the byte array corresponding to string. (2) Convert byte array to string: Use the constructor of the string class to create the string object with the byte array as a parameter, which is the string correspond the byte array).
Regarding claim 43
He further teaches
wherein the generating identifiers includes: obtaining information from the normalized binary specification components; and generating the unique identifiers from the obtained information (¶ 0090-¶0091 - for ID type conversion, sending and feedback are implemented through the data interface and callback interface: The callback interface can be: Send Message success (StringfromID, StringtoID, intmessageID).
Regarding claim 47,
He teaches a system comprising:
a machine or group of machines, each including one or more processors, respectively, for creating a normalized binary specification model(Abstract), including:
a receiver configured to receive one or more existing binary descriptions, wherein each existing binary description is a document that describes aspects of a respective binary communication protocol, binary data storage format, or binary data processing architecture (Abstract - a conversion method for cross-platform communication protocol code, comprising the following steps: defining a binary data based on communication protocol, the communication protocol comprising a protocol head and data entity. said protocol head for storing the length and the communication protocol of the data entity of the protocol signaling, according to communication protocol conversion, comprises the communication protocol content description file, determining the communication protocol needs to be converted into the language type of the content of the description file format conversion - ¶ 0023 – Prepare a description file containing the contents of the universal communication protocol).
an identifier configured to identify a description type of each of the one or more existing binary descriptions (¶ 0024 - Determine the language type that the communication protocol needs to be converted into, and perform format conversion on the content of the description file); and
a categorizer configured to, based on the description type, assign each of the one more existing binary descriptions to a respective loader from a plurality of loaders, wherein each loader of the plurality of loaders is configured to create and output, based on the one or more existing binary descriptions, a normalized binary description. (¶ 0024 - Determine the language type that the communication protocol needs to be converted into, and perform format conversion on the content of the description file - ¶ 0025 - Generate and call the communication protocol interface file - ¶ 0084 – ¶0085 - determine the language type that the communication protocol needs to be converted into, that is, the language platform it will be used for, perform format conversion on the content of the description file, and convert it into a protocol suitable for the platform of the language type to be used - the available communication protocol interface file is generated and the communication protocol interface file can be called – ¶ 0102 – ¶ 0103 - The above steps are explained respectively. For example, the data type is described according to the cross language fixed- Length data type definition, as shown in Table 1 below. The fixed- Length data types of the data types corresponding to different languages have different expressions. According to the XML description file and the corresponding language platform, can be converted accordingly).
Regarding claim 48,
He teaches a method comprising:
creating a normalized binary specification model, including: receiving one or more existing binary descriptions, each of the one or more existing binary descriptions describing at least one of a binary communication protocol, a binary data storage format, or a binary data processing architecture; (Abstract - a conversion method for cross-platform communication protocol code, comprising the following steps: defining a binary data based on communication protocol, the communication protocol comprising a protocol head and data entity. said protocol head for storing the length and the communication protocol of the data entity of the protocol signaling, according to communication protocol conversion, comprises the communication protocol content description file, determining the communication protocol needs to be converted into the language type of the content of the description file format conversion - ¶ 0023 – Prepare a description file containing the contents of the universal communication protocol).
discerning relevant binary information items from within the corresponding one or more binary descriptions (¶ 0029 - The description file includes data types, data objects, request interfaces, and callback interfaces -See ¶ 0088-¶0089 - The description file is defined in XML format. The XML description file includes: data type, data object, request interface, and callback interface. Basic data types include: boolean, int, long, string, list, etc.; the data object is a combination of data in the description file; the data interface is used to request the method name of the server and the parameters that need to be passed in; the callback interface is used to Return the obtained data to the server).
converting the relevant binary information items into normalized binary specification components; (¶ 0051 – The protocol conversion module is used to obtain the data type from the description language and determine the language type that the general communication protocol needs to be converted into).
identifying a description type of each of the one or more existing binary descriptions (¶ 0024 - Determine the language type that the communication protocol needs to be converted into, and perform format conversion on the content of the description file); and
generating identifiers and assigning a respective identifier to each of the normalized binary specification components to produce identified normalized binary specification components; and creating a respective ordered list for each of the identified normalized binary specification components (¶ 0088 – ¶ 0104 - The description file is defined in XML format. The X ML description file includes: data type, data object, request interface, and callback interface. Basic data types include: boolean, int, long, string, list, etc.; the data object isa combination of data in the description file; the data interface is used to request the method name of the server and the parameters that need to be passed in; the callback interface is used to Return the obtained data to the server. For example, for ID type conversion, sending and feedback are implemented through the data interface and callback interface: The request interface can be: Send Message(String from ID ,String to ID ,String message). The Cali back interface can be: Send Message success( String from ID ,String to ID, int message lD) – ¶ 0105 – ¶ 0112 - For example, to determine that the root node tag name of the XML file is Chat Server, set the root node name through < protocol name= "Chat Server">; Define the structure of the communication protocol under the root node: define the structure through < struct name="Group info"></struct>, and the structure name is Group info . Define al I request method sets of the communication protocol under the root node: < request> </request> defines al I request method sets under the root node; Define all callback method sets of the communication protocol under the root node: <callback></callback> under the root node defines all callback method sets);
Regarding claim 50
He further teaches
wherein the converting includes: deconstructing binary information items describing binary types into normalized binary specification types consisting of lists of elementary binary type traits(¶ 0088 – ¶ 0104 - The description file is defined in XML format. The X ML description file includes: data type, data object, request interface, and callback interface. Basic data types include: boolean, int, long, string, list, etc.; the data object isa combination of data in the description file; the data interface is used to request the method name of the server and the parameters that need to be passed in; the callback interface is used to Return the obtained data to the server. For example, for ID type conversion, sending and feedback are implemented through the data interface and callback interface: The request interface can be: Send Message(String from ID ,String to ID ,String message). The Cali back interface can be: Send Message success( String from ID ,String to ID, int message lD) – ¶ 0105 – ¶ 0112 - For example, to determine that the root node tag name of the XML file is Chat Server, set the root node name through < protocol name= "Chat Server">; Define the structure of the communication protocol under the root node: define the structure through < struct name="Group info"></struct>, and the structure name is Group info . Define al I request method sets of the communication protocol under the root node: < request> </request> defines al I request method sets under the root node; Define all callback method sets of the communication protocol under the root node: <callback></callback> under the root node defines all callback method sets);
Regarding claim 51
He further teaches
wherein the converting includes: deconstructing binary information items describing binary rules into normalized binary specification rules consisting of lists of elementary binary rule parameters (¶ 00115-0117 The above method can be used to perform format conversion by writing tools for converting specific language data types and byte arrays to each other. 566 For example: The conversion method between string and byte array in Java is as follows (1:). Convert string to byte array: Directly Cali the get Bytes() method of byte data to return the byte array corresponding to string. (2) Convert byte array to string: Use the constructor of the string class to create the string object with the byte array as a parameter, which is the string correspond the byte array).
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 37 is rejected under 35 U.S.C. 103 as being unpatentable over He in view of Chen et al. Publication No. CN 110531991 A ( Chen hereinafter).
Regarding claim 37,
He further teaches
wherein the normalized binary specification components include:(a) types,(b, normalized binary specification rules (d) normalized binary specification values, (¶ 0051 – according to the data type in the description file and the data type to be converted, call A feature data conversion method to realize he conversion of the feature data - protocol conversion module, used to obtain the data type from the description language and determine the language type that the general communication protocol needs to be converted into; call the characteristic data according to the data type in the description file and the data type to be converted into The conversion method realizes the conversion of the characteristic data – ¶ 0125 -he description file is defined in XML format; the description file includes data type, data object, request interface, and callback interface; the data object is a combination of data in the description file; the data interface is used to request the server The method name and parameters to be passed in; the Cali back interface is used to return the obtained data to the server ¶ 00115-0117 The above method can be used to perform format conversion by writing tools for converting specific language data types and byte arrays to each other. 566 For example: The conversion method between string and byte array in Java is as follows (1:). Convert string to byte array: Directly Cali the get Bytes() method of byte data to return the byte array corresponding to string. (2) Convert byte array to string: Use the constructor of the string class to create the string object with the byte array as a parameter, which is the string correspond the byte array).
However, He does not explicitly teach wherein the specification components include b) normalized binary specification groups, and(e) normalized binary specification actions;
Chen teaches:
wherein the specification components include b) normalized binary specification groups,(c) normalized binary specification rules, and(e) normalized binary specification actions (Page 3 - the file is translated into standardization recordable paper format In the present embodiment, according to corresponding recordable paper format, according to " general recordable paper analyzing platform ", recordable paper Content, according to certain corresponding transformation rule (such as programming read action command byte W:0x57, C:0x43, X: 0x58), (such as burning destination address and the parsing of I2C address extract separation, and such as target register address 0x00, I2C is communicatively Location 0x16), (such as burning byte content by row processing, summarize burning byte length, extract programming content and Inspection it is interior Hold), it is commonly called as " translating " function, final burning information unification is converted into uniformly being aggregated into " one group of burning word with bytewise Section ", is stored in server database with binary data format, is realized for " various document format data " burning text Part information parses extraction standard, forms standardization " burning byte " format, standardization storage is formed, just with various burning formats One burning calling platform of document sharing.(for the Background scheduling file typing of subsequent burning, parameter editor, mistake proofing process is established It builds and provides the foundation, be recordable paper, the fool proof control that programming parameters call provides platform guarantee).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of He to include the teachings of Chen. The motivation for doing so is to allow the system to translate the file into standard format (Chen – Page 3).
Claims 39,49 are rejected under 35 U.S.C. 103 as being unpatentable over He in view of DelGobbo et al. Publication No. US 2016/0162557 A1 (DelGobbo hereinafter)
Regarding claim 39,
He teaches the converting (¶ 0088). However, He does not explicitly teach
normalizing semantics of names in the relevant binary information items into names of the normalized binary specification
DelGobbo teaches
normalizing semantics of names in the relevant binary information items into names of the normalized binary specification (¶ 0066 – Import Tool" defines a bridge identifier used to import semantic layer file 312. "Import Value Map" contains information about semantic layer file 312, such as a location, connection information, options, etc. "export Bridge identifier" defines a bridge identifier used to create converted semantic layer file 224. For example, the bridge creates the MIR XML file that contains a normalized view of semantic layer file 312. "export Value Map" contains a location to store converted semantic layer file 224).
it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of He to include the teachings of DelGobbo. The motivation for doing so is to allow the system to resolve variations and aliases to a single, consistent, and meaningful identifier.
Regarding claim 49,
He teaches the converting (¶ 0088). However, He does not explicitly teach
normalizing semantics of names in the relevant binary information items into names of the normalized binary specification
DelGobbo teaches
normalizing semantics of names in the relevant binary information items into names of the normalized binary specification (¶ 0066 – Import Tool" defines a bridge identifier used to import semantic layer file 312. "Import Value Map" contains information about semantic layer file 312, such as a location, connection information, options, etc. "export Bridge identifier" defines a bridge identifier used to create converted semantic layer file 224. For example, the bridge creates the MIR XML file that contains a normalized view of semantic layer file 312. "export Value Map" contains a location to store converted semantic layer file 224).
it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of He to include the teachings of DelGobbo. The motivation for doing so is to allow the system to resolve variations and aliases to a single, consistent, and meaningful identifier.
Claim 42 is rejected under 35 U.S.C. 103 as being unpatentable over He in view of Menten et al. al. Publication No. US 2011/0030028 A1 (Menten hereinafter) further in view of Fukui et al. Publication No. US 2013/0325534 A1 (Fukui hereinafter).
Regarding claim 42
He does not explicitly teach
wherein the normalized binary specification components include:(f) extensible binary specification details including organization, version, date, and active/inactive status.
However, Menten teaches:
wherein the normalized binary components include: (f) details including organization, version, date (¶ 0020 - multiple versions of the data structures for the same protocol validation specification can be generated from modifications of the original protocol validation specification; and ¶ 0036 – the information of extension-header/header-name on example 3 includes "Content-Type" / "Date" / "Error-Info" /… "MIME-Version" / "Organization"…).
it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of He to include the teachings of Menten. The motivation for doing so is to allow the system to verify that an application protocol payload complies with a binary data structure of protocol validation specification.
Fukui teaches
wherein the normalized binary components include: (f) details including active/inactive status (¶ 0078 - the terminal 104 performs terminal control in accordance with the updated contents of the data model, upon execution of the terminal agent 116. For example, if the data model of "Binary/Software/Status=running" is changed to "Binary/Software/Status=stop", the active software "X" is controlled to stop status; and ¶ 0087 - an attribute name "Binary Software X/Status" represents the active state of the software "X" operating on the terminal 104).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of He to include the teachings of Fukui. The motivation for doing so is to determine the state of binary software.
Claim 44 is rejected under 35 U.S.C. 103 as being unpatentable over He in view of Richardson et al. Patent No. US 9,886,524 B1 ( Richardson hereinafter).
Regarding claim 44
He further teaches
wherein the generating identifiers includes: obtaining information from the normalized binary specification components; generating a first iteration of identifiers from the obtained information (¶ 0090-0091 - for ID type conversion, sending and feedback are implemented through the data interface and callback interface: The callback interface can be: SendMessagesuccess (StringfromID, StringtoID, intmessageID).
However, He does not explicitly teach
checking whether each of the identifiers in the first iteration is unique and, if not, generating a second iteration of identifiers in which the non-unique identifiers from the first iteration are made more complex
Richardson teaches
checking whether each of the identifiers in the first iteration is unique and, if not, generating a second iteration of identifiers in which the non-unique identifiers from the first iteration are made more complex (Col.7, lines 15-20 - the Validation Component is called by MIP Library to validate the Request received from Sterling. Validation first accomplishes the pre-defined validations i.e. Schema validation & Ids validation (whether all the required Ids are present or not and it also checks whether the Ids are unique for the database or not ).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of He to include the teachings of Richardson. The motivation for doing so is to allow the system to maintain data integrity, which prevents errors, inconsistencies, and duplication within the system.
Claims 45-46 are rejected under 35 U.S.C. 103 as being unpatentable over He in view of Kusama et al. Publication No. US 2005/0165848 A1 (Kusama hereinafter).
Regarding claim 45
He does not explicitly teach
providing a domain specific normalized binary specification editing language for a user to edit content of the identified normalized binary specification components.
However, Kusama teaches
providing a domain specific normalized binary specification editing language for a user to edit the content of the identified normalized binary components (¶ 0099 - when an existing data description language is used as that for describing meta-data, existing tools of that data description language can be used upon edit, reference, and the like of meta-data, thus saving extra efforts for development).
It would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the teachings of He to include the teachings of Kusama. The motivation for doing so is to facilitate management of binary data and meta-data.
Regarding claim 46
He does not explicitly teach
providing a domain specific normalized binary specification editing language for a user to edit content of the identified normalized binary specification components, wherein the domain specific normalized binary specification editing language searches for the binary specification component identifiers and changes binary specification component information.
However, Kusama teaches:
providing a domain specific normalized binary specification editing language for a user to edit the content of the identified normalized binary components (¶ 0099 - when an existing data description language is used as that for describing meta-data, existing tools of that data description language can be used upon edit, reference, and the like of meta-data, thus saving extra efforts for development), wherein the domain specific normalized binary specification editing language searches for the identifiers and changes component information (¶ 0086 - when an existing data description language is used as that for describing meta-data, existing tools of that data description language can be used in a search process using meta-data, thus saving extra efforts for development -¶ 0005 - the user describes meta-data in that field. By describing meta-data in such way, data can be easily searched and classified. Since binary data includes meta-data, they can be managed by a single file, thus allowing relatively easy file management. ¶ 0008, ¶ 0023 -It is still another object of the present invention to extract meta-data from binary data in which the meta-data is described, so a