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 .
DETAILED ACTION
This action is in response to the claimed listing filed on 01/19/2024.
Claims 1-20 are pending.
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-8, 11-18, 20 are rejected under 35 U.S.C. 103 as being unpatentable over IBM Document, “COBOL to JSON Schema mapping”, 2021, retrieved from https://www.ibm.com/docs/en/cics-tg-zos/9.2.0?topic=mapping-cobol-json-schema , 6 pages, in view of Redvers Consulting, “COBOL software for JSON generation and parsing - Technical Solutions for COBOL”, 2023, Redvers Consulting Ltd., 4 pages (hereinafter: Redvers).
As per Claim 1: IBM Document discloses,
1. A computer-implemented method comprising:
determining different data types of an element identified by a JSON schema (See in the table in pages 2-6; from page 2 to 4, it identifies COBOL data description, corresponding to JSON Schema definition, in the table, different data types in COBOL are identified as "type":"string", "type":"integer", etc., in the column JSON Schema definition);
generating a static programming language data structure, for a statically typed programming language, that includes different fields identifying the different data types (See in the table in pages 2-6; from page 4 to 6. In the table, different fields in COBOL are identified as "field-name" corresponding to type such as “type”: "array", "type":"string", etc., in the column JSON Schema definition);
generating a metadata file for performing conversations between JSON messages and the statically typed programming language, (JSON Schema is known as ‘metadata’. Referred mapping “COBOL to JSON Schema mapping as in the title - COBOL is the statically typed programming language)
the metadata file identifying the element as a multi-type element and identifying different conversion rules for converting the different data types between the JSON messages and the statically typed programming language (See in p. 1, the first four dashes ‘-’ are the rules, referred to ‘COBOL names are converted to JSON names according to the following rules’ . In the Table in p. 2-6 , the JSON message is the text-based format within ‘{…}’ . Example in page 4, in the third box : “ item”: { data description JSON } ;
and
performing a conversion, of a message that includes the element, between a JSON format and the statically typed programming language,
(See in table in page 2-6: the mapping between JSON Format seen in “Field-Name”: {…} in the right and statically typed programming language COBOL in the left
IBM Document does not explicitly disclose below limitations, and
Redvers Consulting the below limitation:
performing the conversion including:
using, during runtime (Redvers: In p. 2, see Figure arrows in red: Execution time), the static programming language data structure and the static programming language data structure to perform the conversion (Redvers: with an application program, see Figure with the flow of red arrows from COBOL data, the application program converts COBOL into JSON object in Execution time. In p. 3, it is a sample JSON produced from runtime conversion of the Figure in p. 2).
COBOL is known as programming language data structure and the static programming language data structure. IBM document shows rules of mapping from COBOL to JSON Schema. It shows the correlation between of the twos shows so that user can apply the conversion using a program.
Therefore, it would be obvious to an ordinary of skills in the art before the effective filing to combine the static mapping between COBOL and JSON in IBM document, and using an application program, at runtime, to convert COBOL into JSON of Redvers. The combination would yield predictable results because in order for conversion it always requires users to understand the relations, and using conversion at runtime is a common technique of the art.
As per Claim 2: : IBM Document and combining Redvers, where
IBM Document further discloses,
2. The computer-implemented method of claim 1, wherein the message is a JSON message, and wherein performing the conversion comprises:
determining, using the metadata file (Table in p. 2-4, under the boxes “JSON Schema definition”), that the element is a multi-type data element (Table in p. 2-4, under the boxes “JSON Schema definition”, types include “string”, “integer”, “number” etc. )
determining, using the JSON message, a data type of the element (Table in p. 2-4, under the boxes “JSON Schema definition”);
identifying, in the metadata file, a conversion rule regarding the data type identified using the JSON message (In page 1, four dashes that are under “COBOL names are converted to JSON names according to the following rules:”. See Table in p. 4-6, under the boxes “JSON Schema definition” and JSOM message the texts within {..}. Example, in page 4, in the third box : “ item”: { data description JSON } ; and
converting the JSON message to a message of the statically typed programming language using the conversion rule (In page 1, four dashes that are under “COBOL names are converted to JSON names according to the following rules:”).
As per Claim 3: IBM Document and combining Redvers, where
IBM Document further discloses,
3. The computer-implemented method of claim 1, wherein the message is a particular message of the statically typed programming language (See Table in p. 4-6, under the boxes “JSON Schema definition” and JSON message is the texts within {..} that is corresponding to COBOL description in the same row, located in the left. Example, in page 4, in the third box in “JSON Schema definition” is corresponding to COBOL “data description OCCURS n TIMES”), , and wherein performing the conversion comprises:
identifying a field, of the different fields included in the static programming language data structure, that indicates a data type selected for the element in the message of the statically typed programming language;
(Per above limitations, Table in p. 4-6, boxes in “JSON Schema definition” corresponding to “field-name”, and JSON message that is included with “type”)
identifying, in the metadata file, a conversion rule regarding the data type; and
converting the particular message to a JSON message using the conversion rule.
(incorporated with identifying “field-name” and “type” in “JSON Schema definition”, see “COBOL names are converted to JSON names according to the following rules:” in p. 1)
As per Claim 4: IBM Document and combining Redvers, where
IBM Document further discloses,
4. The computer-implemented method of claim 1, wherein determining the different data types comprises: determining the different data types as including a string, a number, an object, an array, and a Boolean.
(All data limitations in claim, string, number, object, array, and Boolean are of COBOL type functions. In the IBM document, it provides in table, and in p. 2-6, referred to "type" which is among with "string", "integer", “number”, “array”, “object”, etc., in the column ‘JSON Schema definition’.
As per Claim 5: IBM Document and combining Redvers, where
IBM Document further discloses,
5. The computer-implemented method of claim 4, wherein generating the metadata file comprises:
generating the metadata file to include a first conversion rule regarding strings,
a second conversion rule regarding numbers,
a third conversion rule regarding objects,
a fourth conversion rule regarding arrays,
and a fifth conversion rule regarding Booleans.
(All above, strings, numbers, objects, arrays, Booleans are types of function in COBOL. In the IBM document, it provides in table, and in p. 2-6, referred to "type" which is among with "string", "integer", “number”, “array”, “object”, etc., along with JSON Message, the defines the FORMAT of conversion.
Example in page with “type”: “array”, it provides the format with maxItem, minItem and items. This format reads the rule of conversion corresponding to type array)
As per Claim 6: IBM Document and combining Redvers, where
IBM Document further discloses,
6. The computer-implemented method of claim 4, wherein generating the static programming language data structure comprises:
generating the static programming language data structure to include
a first field identifying strings,
a second field identifying numbers,
a third field identifying objects,
a fourth field identifying arrays,
and a fifth field identifying Booleans,
wherein the different fields include the first field, the second field, the third field, the fourth field, and the fifth field.
(All above, strings, numbers, objects, arrays, Booleans are types of function in COBOL. In the IBM document, it provides in table, and in p. 2-6, referred to ‘field’ it has “field-name” and further corresponding to “type”. For example reading on limitation “a first field identifying strings”, the IBM reference has format as “field-name’:{“type”: “string”,…} (see in p. 5) , or reading on limitation “a third field identifying objects” , the IBM reference has format as “field-name’:{“type”: “objects”,…} (see in p. 5).
Because the table expresses a mapping from the static programming language data structure COBOL types, therefore others such as numbers, arrays, Booleans would be presented with the same format, and they are reading on the number orders as directed from the field-name and “type”)
As per Claim 7: IBM Document and combining Redvers, where
IBM Document further discloses,
7. The computer-implemented method of claim 6, wherein generating the static programming language data structure comprises:
generating the static programming language data structure to cause two or more fields, of the different fields identifying the different data types,
(Table in p. 2-6, referred to “field-name” with at least two types, in the table, within field-name therefore types of string, array, object.)
IBM Document does not explicitly discloses,
to utilize a same memory location at runtime.
Redvers further discloses above limitation (See Redvers: See Data input to the Conversion Application is at the same Location)
Therefore, it would be obvious to an ordinary of skills in the art before the effective filing to combine the static mapping between COBOL and JSON in IBM document, and using an application program, at runtime, to convert COBOL into JSON of Redvers, with further using memory “the illustration of COBOL data in the green cylinder”. The combination would yield predictable results because it is only conforming to common techniques of the art.
As per Claim 8: Claim is directed to a computer program product where the limitations of the claims perform the method 1. The rejection of the claim would be addressed with the rationales provided in the rejection of the method claim 1.
As per Claim 11: Claim is directed to a computer program product where the limitations of the claims perform the method 4. The rejection of the claim would be addressed with the rationales provided in the rejection of the method claim 4.
As per Claim 12: Claim is directed to a computer program product where the limitations of the claims perform the method 5. The rejection of claim 5 is mapped directed to the IBM Documentation. Therefore, the rejection of the claim 12 would be addressed with the rationales provided in the rejection of the method claim 5 above.
As per Claim 13: Claim is directed to a computer program product where the limitations of the claims perform the method 6. The rejection of the claim 6 is mapped directed to the IBM Documentation. Therefore, the rejection of the claims would be addressed with the rationales provided in the rejection of the method claim 6 above.
As per Claim 14: Claim is directed to a computer program product where the limitations of the claims perform the method 7. The rejection of the claim 7 is mapped directed to the IBM Documentation, and Redvers. Therefore, the rejection of the claim 14 would be addressed with the rationales provided in the rejection of the method claim 7 above.
As per Claim 15: Claim is directed to a computer program product where the limitations of the claims perform the method 3. The rejection of the claim would be addressed with the rationales provided in the rejection of the method claim 3.
As per Claim 16: Claim is directed to a system where the limitations of the claims perform the method 1. The rejection of the claims would be with the rationales addressed in the rejection of the method claim 1.
As per Claim 17: Claim is directed to a system where the limitations of the claims perform the method 7. The rejection of the claim 7 is mapped directed to the IBM Documentation, and Redvers. Therefore, the rejection of the claim 17 would be addressed with the rationales provided in the rejection of the method claim 7 above.
As per Claim 18: Claim is directed to a system where the limitations of the claims perform the method 2. The rejection of the claims would be addressed with the rationales provided in the rejection of the method claim 2.
As per Claim 20: Claim is directed to a system where the limitations of the claims perform the method 3. The rejection of the claim would be addressed with the rationales provided in the rejection of the method claim 3.
Allowable Subject Matter
Claims 9, 10, and 19 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Ted T Vo whose telephone number is (571)272-3706. The examiner can normally be reached 8am-4:30pm ET.
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, Wei Y Mui can be reached on (571) 272-3708. 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.
TTV
November 29, 2025
/Ted T. Vo/
Primary Examiner, Art Unit 2191