Prosecution Insights
Last updated: April 19, 2026
Application No. 18/348,703

NON-TRANSITORY COMPUTER-READABLE STORAGE MEDIUM WITH EXECUTABLE DEVELOPMENT PROGRAM STORED THEREON, INFORMATION PROCESSING SYSTEM, INFORMATION PROCESSING APPARATUS, AND INFORMATION PROCESSING METHOD

Non-Final OA §101§102§103
Filed
Jul 07, 2023
Examiner
KANG, INSUN
Art Unit
2193
Tech Center
2100 — Computer Architecture & Software
Assignee
Nintendo Co., Ltd.
OA Round
3 (Non-Final)
79%
Grant Probability
Favorable
3-4
OA Rounds
3y 5m
To Grant
99%
With Interview

Examiner Intelligence

Grants 79% — above average
79%
Career Allow Rate
515 granted / 655 resolved
+23.6% vs TC avg
Strong +40% interview lift
Without
With
+40.2%
Interview Lift
resolved cases with interview
Typical timeline
3y 5m
Avg Prosecution
23 currently pending
Career history
678
Total Applications
across all art units

Statute-Specific Performance

§101
17.7%
-22.3% vs TC avg
§103
35.2%
-4.8% vs TC avg
§102
19.8%
-20.2% vs TC avg
§112
19.6%
-20.4% vs TC avg
Black line = Tech Center average estimate • Based on career data from 655 resolved cases

Office Action

§101 §102 §103
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 action is responding to the RCE amendment filed on 10/30/2025. Claims 1-13 are pending in the application. Claim Objections Claims 1, 6, 7, 10-13 are objected to because of the following informalities: per claim 1, 6, 7, 10, 11, and 12, a source code, a code needs to be changed to: source code, code respectively. Per claim 13, “an user interface” needs to be changed to: a user interface. Appropriate correction is required. Specification The title of the invention is not descriptive. A new title is required that is clearly indicative of the invention to which the claims are directed. Claim Rejections - 35 USC § 101 35 U.S.C. 101 reads as follows: Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title. Claims 1-13 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Specifically, claims 1-13 are directed to an abstract idea. Per claim 1, the claim is directed to an idea of itself, mental processes that can be performed in the human mind, or by a human using a pen and paper. The steps of identifying a type definition in source code and generating code can be pure mental processes. The claim does not recite how the generating step is performed or implemented in particular manners. A developer can write code based on type definition in code. The additional limitation, the one or more processors is recited in the preamble and described at a high level of generality for applying or performing the abstract idea and do not indicate any integration of the abstract idea into a practical application as the mental steps are merely applied with a generic computing component(s). See MPEP see MPEP 2106.05(f) /2106.05(h). It is noted that employing generic computer functions to execute an abstract idea, even when limiting the use of the idea to one particular environment, does not add significantly more, similar to how limiting the abstract idea in Flook to petrochemical and oil-refining industries was insufficient. Therefore, the additional limitations do not integrate the abstract idea into a practical application. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, but for the recitation of generic computer components or insignificant extra solution activities (e.g. processors, devices, program instructions), then it falls within the "Mental Processes" grouping of abstract ideas (2019 PEG step 2A, Prong 1: Abstract idea grouping? Yes, Mental Process). Viewing the limitations individually and as a combination, the additional elements merely perform the mental steps using generic computing components as tools without integrating the abstract idea into a practical application. For at least these reasons, claim 1 is not patent eligible. Per claims 2-9, these claims are directed to the same idea itself as in claim 1, reciting details of the mental steps and code elements without adding any other additional element that is significantly more. Furthermore, the details of generation of an intermediate object is not recited and a developer can generate an intermediate object based on a definition description as data and code do not need to be large. Therefore, the claims are rejected for the same reasons as in claim 1. Per claims 10, 11 and 12, the claims are directed to the same idea itself as in claim 1, reciting only the same mental steps without adding any other additional element that is significantly more. The additional elements, a memory and processors in claims 10 and 11 and computer in claim 12 are recited as generic computing components. Therefore, the claims are rejected for the same reasons as in claim 1. Per claim 13, this claim is directed to the same idea itself as in claim 10, reciting details of the mental steps and code elements without adding any other additional element that is significantly more. The additional limitations, the step of receiving edits is mere data gathering for the mental steps while the user interface is described at a high level of generality for the data gathering and do not indicate any integration of the abstract idea into a practical application as the mental steps are merely applied with a generic computing component(s). See MPEP see MPEP 2106.05(f) /2106.05(h). It is noted that employing generic computer functions to execute an abstract idea, even when limiting the use of the idea to one particular environment, does not add significantly more, similar to how limiting the abstract idea in Flook to petrochemical and oil-refining industries was insufficient. Therefore, the additional limitations do not integrate the abstract idea into a practical application. If a claim limitation, under its broadest reasonable interpretation, covers performance of the limitation in the mind, but for the recitation of generic computer components or insignificant extra solution activities (e.g. processors, devices, program instructions), then it falls within the "Mental Processes" grouping of abstract ideas (2019 PEG step 2A, Prong 1: Abstract idea grouping? Yes, Mental Process). At most, the receiving step is not found to include anything more than what is well-understood, routine, conventional activity in the field. In this case, it is noted that the claimed extra-solution of data gathering is acknowledged to be a well-understood, routine, conventional activity court recognized as WURC examples in MPEP 2106.05(d)(ll), for example, data gathering and retrieving, storing data, transmitting/displaying a result - Symantec, Versata Dev, Content extraction, Electric Power Group). Insignificant extra solution activities or mere instructions to apply an exception using generic computer components cannot provide an inventive concept. Viewing the limitations individually and as a combination, the additional elements merely perform data gathering for the mental steps and perform the mental steps using generic computing components as tools without integrating the abstract idea into a practical application. For at least these reasons, claim 13 is not patent eligible. Claim Rejections - 35 USC § 102 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action: A person shall be entitled to a patent unless – (a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention. Claim Rejections - 35 USC § 103 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. The following is a quotation of 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-3, 5-8, and 10-13 are rejected under 35 U.S.C. 103 as being unpatentable over Benton (US20180246708) in view of Evans (US20160004729). Per claim 1: Benton discloses: A non-transitory computer-readable storage medium with an executable development program stored thereon, the development program being for development of an application program with a programming language in which an object is generated based on a type, the development program causing one or more processors of an information processing apparatus to perform: identifying a type definition in a source code of the application program ; (Benton, see at least [0005] In another example, a computing device is provided. The computing device includes a memory, and a processor device coupled to the memory. The processor device is to receive a plurality of source code instructions in a computer programming language that includes a data object definition associated with a data object type and a plurality of function definitions that accesses a data object of the data object type. The processor device is further to generate, based on the plurality of function definitions, a corresponding plurality of intermediate functions, each intermediate function comprising a plurality of intermediate code instructions; [0022]; [0035] in this case data objects of the type defined by the data object definitions 62-1-62-5, received and/or returned by the intermediate functions 70; [0044] receives the plurality of source code instructions 60 in a computer programming language that includes data object definitions 62-1-62-5 associated with the data object types A-E, and the plurality of function definitions 64-1-64-5 that accesses data objects of the data object types A-E (FIG. 3, block 1000); [0047]); and generating a first code that generates an intermediate object for asset data corresponding to each of objects generated based on the identified type definition; wherein the intermediate object is stored as the asset data (Benton, see at least [0034] A data object serialization generator 24-1, based on the data object definitions 62-1-62-5, automatically generates a plurality of data object serializers 66-1-66-5, each of which comprises intermediate code instructions configured to serialize a data object of the data object type defined by the corresponding data object definition 62-1-62-5 into a data object stream. The data object serialization generator 24-1, based on the data object definitions 62-1-62-5, also automatically generates a plurality of data object deserializers 68-1-68-5, each of which comprises intermediate code instructions configured to deserialize a data object stream into a data object of the data object type defined by the corresponding data object definition 62-1-62-5; [0025]; [0035] An intermediate code instruction generator 34-1 generates, based on the plurality of function definitions 64-1-64-5, a corresponding plurality of intermediate functions 70-1-70-5 (generally, intermediate functions 70), each intermediate function 70 comprising a plurality of intermediate code instructions that implement the function defined by the corresponding function definition 64). Benton discloses that the generated intermediate functions of the data object serializers result in generation of native source code instruction sets during a second stage compilation ([0034]; [0035]; [0044]; [0047]) which can indicate that the generated source code instruction sets incorporate the generated intermediate functions. However, Benton does not explicitly teach adding code to the source code of the application program in which the type definition was identified where the source code and the code generated are both editable by a user. Nonetheless, Evans teaches adding the generated code to the source code of the application program in which the type definition was identified, where the source code and the code generated are both editable by a user (Evans, see at least [0029]; [0030]; [0031] The Source Code Generator 4 comprises a computer programs or component such as Integrated Development Environment (IDE) that generates data objects and views; [0035] Once generated,…the Source Code 5 may be compiled into classes, and then directly injected e.g., via Java, into the Distributed Application 7; [0039]; [0050] In operation, a developer may make a change to the Master Schema 1, regenerate the Schema(s) 3 using the Schema Generator 2, and provide the Schema 3 to the Schema Enforcer 6, wherein the Schema Enforce 6 is a source code compiler. Alternatively, the Master Schema 1, containing annotations, may be directly provided to the Schema Enforcer 6. The developer may then modify the Source Code 5, and use the Schema Enforcer 6 to ensure that the changes made to the Source Code 5 are compliant; [0053] In this way, making changes to the Master Schema 1 allows a software developer to re-generate or modify code automatically and use the Schema Enforcers 6 to ensure that changes to the Source Code 5 made by the Source Code Generator 4 are in compliance. In this embodiment of the present invention, therefore, a developer can rapidly modify and test code without the expense of large software engineering and quality assurance teams). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Evans’ code edition enablement with Benton’s code generation for serialization to modify Benton’s system to combine the code editability function as taught by Evans, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to code development or serialization. Combining Evans’ functionality with that of Benton results in a system that allows adding code and code edit by a user. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to allow code edit by a user including code injection by a user (Evans, see at least [0029]; [0030]; [0031] The Source Code Generator 4 comprises a computer programs or component such as Integrated Development Environment (IDE) that generates data objects and views; [0035] Once generated,…the Source Code 5 may be compiled into classes, and then directly injected e.g., via Java, into the Distributed Application 7; [0039]; [0050] In operation, a developer may make a change to the Master Schema 1, regenerate the Schema(s) 3 using the Schema Generator 2, and provide the Schema 3 to the Schema Enforcer 6, wherein the Schema Enforce 6 is a source code compiler. Alternatively, the Master Schema 1, containing annotations, may be directly provided to the Schema Enforcer 6. The developer may then modify the Source Code 5, and use the Schema Enforcer 6 to ensure that the changes made to the Source Code 5 are compliant; [0053] In this way, making changes to the Master Schema 1 allows a software developer to re-generate or modify code automatically and use the Schema Enforcers 6 to ensure that changes to the Source Code 5 made by the Source Code Generator 4 are in compliance. In this embodiment of the present invention, therefore, a developer can rapidly modify and test code without the expense of large software engineering and quality assurance teams). 2. The non-transitory computer-readable storage medium according to claim 1, wherein the development program further causes the one or more processors to add a serialization definition description to the type definition the source code of the application program, and the intermediate object is generated in accordance with the serialization definition (Benton, see at least [0025] The data object serialization generator 24 also operates to generate intermediate data object deserializers 28, 32 that are configured to deserialize a data object stream into a data object of the data object type. … ; [0034] A data object serialization generator 24-1, based on the data object definitions 62-1-62-5, automatically generates a plurality of data object serializers 66-1-66-5, each of which comprises intermediate code instructions configured to serialize a data object of the data object type defined by the corresponding data object definition 62-1-62-5 into a data object stream; Note that the data object serialization generator 24 generates the data object serializer 26 and the data object deserializer 28 automatically). 3. The non-transitory computer-readable storage medium according to claim 2, wherein a portion of the code for the type of the intermediate object is defined independently of the type definition in a corresponding source code (Benton, see at least [0021] domain-specific language programs exist independently of host-language programs. In some examples, the source code instructions 18 are in an embedded domain specific language and can be used in conjunction with other programming languages; [0025] The data object serialization generator 24 also operates to generate intermediate data object deserializers 28, 32 that are configured to deserialize a data object stream into a data object of the data object type. In this example, based on the data object definition 20-1, the first stage compiler 12 automatically generates a data object deserializer 28 that comprises intermediate code instructions configured to deserialize a data object stream into a data object of the data object type defined by the data object definition 20-1. [0035] An intermediate code instruction generator 34-1 generates, based on the plurality of function definitions 64-1-64-5, a corresponding plurality of intermediate functions 70-1-70-5 (generally, intermediate functions 70), each intermediate function 70 comprising a plurality of intermediate code instructions that implement the function defined by the corresponding function definition 64; Note that the data object serialization generator 24 generates the data object serializer 26 and the data object deserializer 28 automatically). 5. The non-transitory computer-readable storage medium according to claim 2, wherein the development program further causes the one or more processors to add a code to the type definition in the source code of the application program for performing processing for calling processing for holding in the intermediate object, a value obtained by a function designated in advance or a value designated in advance (Benton, see at least [0020] The source code instructions 18 include one or more data object definitions 20-1, 20-2 (generally, data object definitions 20), and a plurality of function definitions 22-1-22-N (generally, function definitions 22). … the data object definitions 20 may comprise: scalar numeric types … i.e., unordered collections of distinct values, with the set type parameterized by the element type … the head is a value of X and the tail is a list of X, and the empty list is a 0-arity tuple; [0022] a function definition 22 may include a function name, a function type, and a function body. Function names may be arbitrary identifiers used to refer to functions elsewhere in a program. Function types include the input types for each function argument and the result type of the function; for example, “max”, a function to identify the largest of two integers might have the type (Int, Int)->Int, indicating that the max function takes two integer values and returns one integer value. A function body may be an expression). Per claim 6: Benton further discloses: The non-transitory computer-readable storage medium according to claim 2, wherein the development program further causes the one or more processors to add a code to the type definition in the source code of the application program for performing processing for calling processing for passing a value of a property held in the intermediate object to a function designated in advance (Benton, see at least [0022] The function definitions 22 implement desired behavior. By way of non-limiting examples, and in particular in a machine learning context, a function definition 22 may include a function name, a function type, and a function body. Function names may be arbitrary identifiers used to refer to functions elsewhere in a program. Function types include the input types for each function argument and the result type of the function; for example, “max”, a function to identify the largest of two integers might have the type (Int, Int)->Int, indicating that the max function takes two integer values and returns one integer value; Note that the primitive data type, Int arguments are passed to a function/method by value). 7. The non-transitory computer-readable storage medium according to claim 2, wherein the development program further causes the one or more processors to add a code to the type definition in the source code of the application program for performing processing for calling processing for outputting a value of a property of the intermediate object in a predetermined format for each type of the intermediate object (Benton, see at least [0032], The function V outputs a data object defined by the data object definition 62-4 (i.e., a data object of type D). A function W (defined by the function definition 64-2) receives, as input, a data object defined by the data object definition 62-2 (i.e., a data object of type B). The function W outputs a data object defined by the data object definition 62-5 (i.e., a data object of type E); [0024] A program, or function, in the IR has the same meaning as the source code instructions 18 it was generated from, but has been converted into a simpler form that is easier to analyze). 8. The non-transitory computer-readable storage medium according to claim 1, wherein the identifying a type definition includes extracting, from the source code of the application program, the serialization definition description including a first description that designates a name of a property and a second description that designates a function or a variable for obtaining a value (Benton, see at least [0020] The data object definitions 20 identify data structures that are utilized by the function definitions 22…. parameterized sum types, or tagged unions, so that a single type may include values with multiple shapes. As an example, a list with elements of X as a sum type could be declared as follows: a list of X is either a cell of X or the empty list, a cell of X is a record with two fields: the head is a value of X and the tail is a list of X, and the empty list is a 0-arity tuple; [0022] a function definition 22 may include a function name, a function type, and a function body… The binding list is a sequence of pairs of variable names and expressions). Per claim 10, it is the system version of claim 1, and is rejected for the same reasons set forth in connection with the rejection of claim 1 above. 11. An information processing apparatus comprising: one or more processors; and a memory where a program is stored, wherein the information processing apparatus is configured to perform, by execution of the program by the one or more processors, identifying a type definition in a source code of an application program described in a programming language in which an object is generated based on a type; (Benton, see at least [0005] In another example, a computing device is provided. The computing device includes a memory, and a processor device coupled to the memory. The processor device is to receive a plurality of source code instructions in a computer programming language that includes a data object definition associated with a data object type and a plurality of function definitions that accesses a data object of the data object type. The processor device is further to generate, based on the plurality of function definitions, a corresponding plurality of intermediate functions, each intermediate function comprising a plurality of intermediate code instructions; [0022]; [0035] in this case data objects of the type defined by the data object definitions 62-1-62-5, received and/or returned by the intermediate functions 70; [0044] receives the plurality of source code instructions 60 in a computer programming language that includes data object definitions 62-1-62-5 associated with the data object types A-E, and the plurality of function definitions 64-1-64-5 that accesses data objects of the data object types A-E (FIG. 3, block 1000); [0047]); and generating a code that generates an intermediate object for asset data corresponding to each of objects generated based on the identified type definition and wherein the intermediate object is stored as the asset data (Benton, see at least [0034] A data object serialization generator 24-1, based on the data object definitions 62-1-62-5, automatically generates a plurality of data object serializers 66-1-66-5, each of which comprises intermediate code instructions configured to serialize a data object of the data object type defined by the corresponding data object definition 62-1-62-5 into a data object stream. The data object serialization generator 24-1, based on the data object definitions 62-1-62-5, also automatically generates a plurality of data object deserializers 68-1-68-5, each of which comprises intermediate code instructions configured to deserialize a data object stream into a data object of the data object type defined by the corresponding data object definition 62-1-62-5; [0025]; [0035] An intermediate code instruction generator 34-1 generates, based on the plurality of function definitions 64-1-64-5, a corresponding plurality of intermediate functions 70-1-70-5 (generally, intermediate functions 70), each intermediate function 70 comprising a plurality of intermediate code instructions that implement the function defined by the corresponding function definition 64). Benton discloses that the generated intermediate functions of the data object serializers result in generation of native source code instruction sets during a second stage compilation ([0034]; [0035]; [0044]; [0047]) which can indicate that the generated source code instruction sets incorporate the generated intermediate functions. However, Benton does not explicitly teach adding code to the source code of the application program in which the type definition was identified where the source code and the code generated are both editable by a user. Nonetheless, Evans teaches adding the generated code to the source code of the application program in which the type definition was identified, where the source code and the code generated are both editable by a user (Evans, see at least [0029]; [0030]; [0031] The Source Code Generator 4 comprises a computer programs or component such as Integrated Development Environment (IDE) that generates data objects and views; [0035] Once generated,…the Source Code 5 may be compiled into classes, and then directly injected e.g., via Java, into the Distributed Application 7; [0039]; [0050] In operation, a developer may make a change to the Master Schema 1, regenerate the Schema(s) 3 using the Schema Generator 2, and provide the Schema 3 to the Schema Enforcer 6, wherein the Schema Enforce 6 is a source code compiler. Alternatively, the Master Schema 1, containing annotations, may be directly provided to the Schema Enforcer 6. The developer may then modify the Source Code 5, and use the Schema Enforcer 6 to ensure that the changes made to the Source Code 5 are compliant; [0053] In this way, making changes to the Master Schema 1 allows a software developer to re-generate or modify code automatically and use the Schema Enforcers 6 to ensure that changes to the Source Code 5 made by the Source Code Generator 4 are in compliance. In this embodiment of the present invention, therefore, a developer can rapidly modify and test code without the expense of large software engineering and quality assurance teams). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Evans’ code edition enablement with Benton’s code generation for serialization to modify Benton’s system to combine the code editability function as taught by Evans, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to code development or serialization. Combining Evans’ functionality with that of Benton results in a system that allows adding code and code edit by a user. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to allow code edit by a user including code injection by a user (Evans, see at least [0029]; [0030]; [0031] The Source Code Generator 4 comprises a computer programs or component such as Integrated Development Environment (IDE) that generates data objects and views; [0035] Once generated,…the Source Code 5 may be compiled into classes, and then directly injected e.g., via Java, into the Distributed Application 7; [0039]; [0050] In operation, a developer may make a change to the Master Schema 1, regenerate the Schema(s) 3 using the Schema Generator 2, and provide the Schema 3 to the Schema Enforcer 6, wherein the Schema Enforce 6 is a source code compiler. Alternatively, the Master Schema 1, containing annotations, may be directly provided to the Schema Enforcer 6. The developer may then modify the Source Code 5, and use the Schema Enforcer 6 to ensure that the changes made to the Source Code 5 are compliant; [0053] In this way, making changes to the Master Schema 1 allows a software developer to re-generate or modify code automatically and use the Schema Enforcers 6 to ensure that changes to the Source Code 5 made by the Source Code Generator 4 are in compliance. In this embodiment of the present invention, therefore, a developer can rapidly modify and test code without the expense of large software engineering and quality assurance teams). Per claim 12, it is the method version of claim 1, and is rejected for the same reasons set forth in connection with the rejection of claim 1 above. Per claim 13: Benton does not explicitly teach a user interface configured to receive edits to the source code and the code generated. Evans teaches a user interface configured to receive edits to the source code and the code generated (Evans, see at least [0029]; [0030]; [0031] The Source Code Generator 4 comprises a computer programs or component such as Integrated Development Environment (IDE) that generates data objects and views; [0035] Once generated,…the Source Code 5 may be compiled into classes, and then directly injected e.g., via Java, into the Distributed Application 7; [0039]; [0050] In operation, a developer may make a change to the Master Schema 1, regenerate the Schema(s) 3 using the Schema Generator 2, and provide the Schema 3 to the Schema Enforcer 6, wherein the Schema Enforce 6 is a source code compiler. Alternatively, the Master Schema 1, containing annotations, may be directly provided to the Schema Enforcer 6. The developer may then modify the Source Code 5, and use the Schema Enforcer 6 to ensure that the changes made to the Source Code 5 are compliant; [0053] In this way, making changes to the Master Schema 1 allows a software developer to re-generate or modify code automatically and use the Schema Enforcers 6 to ensure that changes to the Source Code 5 made by the Source Code Generator 4 are in compliance. In this embodiment of the present invention, therefore, a developer can rapidly modify and test code without the expense of large software engineering and quality assurance teams). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Evans’ user interface for code edition with Benton’s code generation for serialization to modify Benton’s system to combine the code editability function as taught by Evans, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to code development or serialization. Combining Evans’ functionality with that of Benton results in a system that incorporates a user interface for code edits. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to facilitates code edit via a user interface (Evans, see at least [0029]; [0030]; [0031] The Source Code Generator 4 comprises a computer programs or component such as Integrated Development Environment (IDE) that generates data objects and views; [0035] Once generated,…the Source Code 5 may be compiled into classes, and then directly injected e.g., via Java, into the Distributed Application 7; [0039]; [0050] In operation, a developer may make a change to the Master Schema 1, regenerate the Schema(s) 3 using the Schema Generator 2, and provide the Schema 3 to the Schema Enforcer 6, wherein the Schema Enforce 6 is a source code compiler. Alternatively, the Master Schema 1, containing annotations, may be directly provided to the Schema Enforcer 6. The developer may then modify the Source Code 5, and use the Schema Enforcer 6 to ensure that the changes made to the Source Code 5 are compliant; [0053] In this way, making changes to the Master Schema 1 allows a software developer to re-generate or modify code automatically and use the Schema Enforcers 6 to ensure that changes to the Source Code 5 made by the Source Code Generator 4 are in compliance. In this embodiment of the present invention, therefore, a developer can rapidly modify and test code without the expense of large software engineering and quality assurance teams). Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Benton in view of Evans and Stairs et al. (US 20170337038, hereafter Stairs). Per claim 4: Benton does not explicitly teach wherein in the serialization definition description, the type of the intermediate object is defined to inherit a common type definition. Stairs teaches wherein in the second code, the type of the intermediate object is defined to inherit a common type definition (Stairs, see at least [0003] Although separate classes can be defined for each vehicle type, each class defining data members for the common attributes along with data members for the vehicle type-specific attributes, OOP inheritance allows the common attributes to be defined once and then inherited by the vehicle type-specific classes. The Vehicle class defines the data members and methods that are common to all vehicles. The inheritance of the Vehicle class by a Car class). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Stairs’ OOP inheritance with Benton’s code generation for serialization and Evans’s code edit to modify Benton’s system to combine the inheritance function as taught by Stairs, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to code development or serialization. Combining Stairs’ functionality with that of Benton and Evans results in a system that allows common type definition inheritance. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to allow common attributes to be defined once and then inherited by type specific classes (Stairs, see at least [0003] Although separate classes can be defined for each vehicle type, each class defining data members for the common attributes along with data members for the vehicle type-specific attributes, OOP inheritance allows the common attributes to be defined once and then inherited by the vehicle type-specific classes. The Vehicle class defines the data members and methods that are common to all vehicles. The inheritance of the Vehicle class by a Car class). Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Benton in view of Evans and Yoshinori (JP2018032154, cited). Per claim 9: Benton does not explicitly teach wherein the development program further causes the one or more processors to add another code that performs processing for holding a history of the intermediate object to the source code of the application program. Yoshinori teaches wherein the development program further causes the one or more processors to add a third code that performs processing for holding a history of the intermediate object to the source code of the application program (Yoshinori, see at least page 2, A conventional serializer cannot collectively deserialize a whole class, because it does not hold the class definition of an old version. A serializer of the present invention prepares a conversion program between any version and a previous version, repeats version up/down conversion, and hence can achieve storage/recovery of class/instance in all versions. In the present invention, the class definition of the old version is held, so that a conventional serializer technology can be applied also to a class of a previous version). It would have been obvious for one having ordinary skill in the art before the effective filing date of the claimed invention to have combined Yoshinori’s holding a history of conversions with Benton’s code generation for serialization and Evans’s code edit to modify Benton’s system to combine the inheritance function as taught by Stairs, with a reasonable expectation of success, since they are analogous art because they are from the same field of endeavor related to code development or serialization. Combining Yoshinori’s functionality with that of Benton and Evans results in a system that allows code conversion history holding. The modification would be obvious because one having ordinary skill in the art would be motivated to make this combination to allow storage/recovery of class/instance in all versions (Yoshinori, see at least Page 2, A conventional serializer cannot collectively deserialize a whole class, because it does not hold the class definition of an old version. A serializer of the present invention prepares a conversion program between any version and a previous version, repeats version up/down conversion, and hence can achieve storage/recovery of class/instance in all versions. In the present invention, the class definition of the old version is held, so that a conventional serializer technology can be applied also to a class of a previous version). Examiner’s Note The Examiner has pointed out particular references contained in the prior art of record within the body of this action for the convenience of the Applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply. Applicant, in preparing the response, should consider fully the entire reference as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the Examiner. Response to Arguments Applicant’s arguments with respect to claim(s) 1-13 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument. Conclusion The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. CN-112130837-A is related to generating serialized code according to a description file. Any inquiry concerning this communication or earlier communications from the examiner should be directed to INSUN KANG whose telephone number is (571)272-3724. The examiner can normally be reached M-TR 8 -5pm; week 2: Tu-F 8-5pm. Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Chat Do can be reached at 571-272-3721. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300. 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. /INSUN KANG/Primary Examiner, Art Unit 2193
Read full office action

Prosecution Timeline

Jul 07, 2023
Application Filed
Nov 30, 2024
Non-Final Rejection — §101, §102, §103
Apr 04, 2025
Response Filed
Jul 26, 2025
Final Rejection — §101, §102, §103
Oct 22, 2025
Applicant Interview (Telephonic)
Oct 22, 2025
Examiner Interview Summary
Oct 30, 2025
Request for Continued Examination
Nov 03, 2025
Response after Non-Final Action
Nov 29, 2025
Non-Final Rejection — §101, §102, §103
Mar 10, 2026
Applicant Interview (Telephonic)
Mar 10, 2026
Examiner Interview Summary

Precedent Cases

Applications granted by this same examiner with similar technology

Patent 12596632
METHOD FOR TESTING A COMPUTER PROGRAM
2y 5m to grant Granted Apr 07, 2026
Patent 12578981
GAME TRANSLATION METHOD, AND ELECTRONIC DEVICE, AND COMPUTER READABLE MEDIUM THEREOF
2y 5m to grant Granted Mar 17, 2026
Patent 12578945
INSTANT INSTALLATION OF APPS
2y 5m to grant Granted Mar 17, 2026
Patent 12530211
SYSTEMS AND METHODS FOR DYNAMIC SERVER CONTROL BASED ON ESTIMATED SCRIPT COMPLEXITY
2y 5m to grant Granted Jan 20, 2026
Patent 12498906
INLINE CONVERSATION WITH ARTIFICIAL INTELLIGENCE WITHIN CODE EDITOR USER INTERFACE
2y 5m to grant Granted Dec 16, 2025
Study what changed to get past this examiner. Based on 5 most recent grants.

AI Strategy Recommendation

Get an AI-powered prosecution strategy using examiner precedents, rejection analysis, and claim mapping.
Powered by AI — typically takes 5-10 seconds

Prosecution Projections

3-4
Expected OA Rounds
79%
Grant Probability
99%
With Interview (+40.2%)
3y 5m
Median Time to Grant
High
PTA Risk
Based on 655 resolved cases by this examiner. Grant probability derived from career allow rate.

Sign in with your work email

Enter your email to receive a magic link. No password needed.

Personal email addresses (Gmail, Yahoo, etc.) are not accepted.

Free tier: 3 strategy analyses per month