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 the amendment filed 8/11/2025.
Claims 4 and 11 have been amended.
Claims 1-3 and 20-28 have been canceled.
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 4-11, 18, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over CN112241370A to Fan in view of U.S. Pub. No. 20160013989 to Chouhan.
Per claim 4, Fan teaches a method for converting between a plurality of code types for a client application wherein there is a mismatch between one or more of the plurality of code types comprising:
triggering a reflection of a current set of application programming interfaces (APIs) (see at least page 29 “...mode two, using reflection technology, traversing an API interface type and embedded interface type thereof…”);
creating matching code at compile time for the client application to provide at runtime (see at least page 29 “Step 501: A reflection creates an API interface class…”); and
communicating with the cloud-hosted services (see at least page 31, “…Step 302: after reporting each attribute information set to the management server…”).
Chouhan teaches an analogous art relates to Java reflection for creating object, comprising:
scanning through a plurality of endpoints of cloud-hosted services and data transfer objects (see at least paragraph [0006] “… The example interface 32 is adapted to run the discovery/analysis tool 42, which includes computer code for using one or more Java reflection APIs 38 and Java predicate APIs 40 to analyze the Java-based entities 18-28; particularly the Java services 18, 20, to determine if they are suitable for conversion to REST services…”).
It would have been obvious for a person of an ordinary skilled in the art as of the effective filing date of the claimed invention to modify the teaching of Fan to incorporate the teaching of Chouhan to determine one or more Java services. One would have motivated to identify the services in order find a right service for data conversion.
Per claim 5, Fan further teaches
wherein converting between a plurality of code types provides platform independent interoperability (see at least page 18 “Development equipment: The developer develops, compiles, modifies the source code project, and the device used when generating the installable data packet based on the source code project, can be an independent electronic device, or a combination of electronic device…”).
Per claim 6, Chouhan further teaches
wherein the reflection is a C++ reflection (see at last paragraph [0059] “Any suitable programming language can be used to implement the routines of particular embodiments including C, C++, Java, assembly language, etc. Different programming techniques can be employed such as procedural or object oriented…”).
Per claim 7, Chouhan further teaches
wherein the matching code is C++ code (see at least paragraph [0026] “The example JEE system(s) supports various Java services 18, 20, a converted REST service 28 (that has been converted from a Java service), a Business Prosecution Language (BPEL) composite 26, and a Java API 24”; see at last paragraph [0059] “Any suitable programming language can be used to implement the routines of particular embodiments including C, C++, Java, assembly language, etc. Different programming techniques can be employed such as procedural or object oriented…”).
Per claim 8, Chouhan further teaches
wherein the reflection is a C# reflection (see at last paragraph [0059] “Any suitable programming language can be used to implement the routines of particular embodiments including C, C++, Java, assembly language, etc. Different programming techniques can be employed such as procedural or object oriented…”).
Per claim 9, Chouhan further teaches
wherein the matching code is C# code (see at least paragraph [0026] “The example JEE system(s) supports various Java services 18, 20, a converted REST service 28 (that has been converted from a Java service), a Business Prosecution Language (BPEL) composite 26, and a Java API 24”; see at last paragraph [0059] “Any suitable programming language can be used to implement the routines of particular embodiments including C, C++, Java, assembly language, etc. Different programming techniques can be employed such as procedural or object oriented…”).
Per claim 10, Chouhan further teaches
wherein the reflection is a WebAssembly reflection (see at last paragraph [0059] “Any suitable programming language can be used to implement the routines of particular embodiments including C, C++, Java, assembly language, etc. Different programming techniques can be employed such as procedural or object oriented…”).
Per claim 11, Chouhan further teaches
wherein the matching code is WebAssembly code (see at least paragraph [0026] “The example JEE system(s) supports various Java services 18, 20, a converted REST service 28 (that has been converted from a Java service), a Business Prosecution Language (BPEL) composite 26, and a Java API 24”; see at last paragraph [0059] “Any suitable programming language can be used to implement the routines of particular embodiments including C, C++, Java, assembly language, etc. Different programming techniques can be employed such as procedural or object oriented…”).
Per claim 18, Chouhan further teaches
wherein the reflection is a Java reflection (see at last paragraph [0059] “Any suitable programming language can be used to implement the routines of particular embodiments including C, C++, Java, assembly language, etc. Different programming techniques can be employed such as procedural or object oriented…”).
Per claim 19, Chouhan further teaches
wherein the matching code is Java code (see at least paragraph [0026] “The example JEE system(s) supports various Java services 18, 20, a converted REST service 28 (that has been converted from a Java service), a Business Prosecution Language (BPEL) composite 26, and a Java API 24”; see at last paragraph [0059] “Any suitable programming language can be used to implement the routines of particular embodiments including C, C++, Java, assembly language, etc. Different programming techniques can be employed such as procedural or object oriented…”).
Claims 12 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over CN112241370A to Fan in view of U.S. Pub. No. 20160013989 to Chouhan and in further view of U.S. Pub. No. 20210224227 to Merrill.
Per claim 12, neither Fan nor Chouhan explicitly teach
wherein the reflection is a python reflection.
Merrill teaches an analogous art relates to transforming code, comprising:
reflection is a python reflection (see at least paragraph [0076] “a transform (e.g. 950) can be a function that uses two or more variables and returns at least one computed metavariable. The list of dependencies (e.g. 952) and the list of siblings (e.g. 954) can be related only by the fact that the list of dependencies are used to construct the list of siblings through the specified transformation; the two lists need not be the same length nor need the elements of the two lists match up in any way in some embodiments. A transform member can be the name of a function that performs the transform. The function to which a given transform name is associated can be looked up by name when a UMD file is loaded. This operation can be accomplished in languages which support reflection, such as Java, R, S-plus or Python. Additionally, this operation can be accomplished in languages which support dynamic loading by name, such a C or C++ or in any language with access to a DLL's symbol table in Windows environments”).
It would have been obvious for a person of an ordinary skilled in the art as of the effective filing date of the claimed invention to modify the teachings of Fan and Chouhan to incorporate the teaching of Merrill to use python reflection. One would have been motivated to use python reflection to implement and interact with data type and objects at runtime.
Per claim 13, Merrill further teaches
wherein the matching code is python code (see at least paragraph [0076] “a transform (e.g. 950) can be a function that uses two or more variables and returns at least one computed metavariable. The list of dependencies (e.g. 952) and the list of siblings (e.g. 954) can be related only by the fact that the list of dependencies are used to construct the list of siblings through the specified transformation; the two lists need not be the same length nor need the elements of the two lists match up in any way in some embodiments. A transform member can be the name of a function that performs the transform. The function to which a given transform name is associated can be looked up by name when a UMD file is loaded. This operation can be accomplished in languages which support reflection, such as Java, R, S-plus or Python. Additionally, this operation can be accomplished in languages which support dynamic loading by name, such a C or C++ or in any language with access to a DLL's symbol table in Windows environments”).
Claims 14 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over CN112241370A to Fan in view of U.S. Pub. No. 20160013989 to Chouhan and in further view of “iOS 12 Programming Fundamentals with Swift” to Neuburg.
Per claim 14, neither Fan nor Chouhan teaches
wherein the reflection is a Swift reflection.
Neuburg teaches an analogous art relates to Swift reflection, comprises:
a Swift reflection (see at least page 290 “Introspection. Swift provides limited ability to introspect an object, letting an object display the names and values of its properties. This feature is intended for debugging, not for use in your program’s logic. For example, you can use it to modify the way your object is displayed in the Xcode Debug pane. To introspect an object, use it as the reflecting: parameter when you instantiate a Mirror. The Mirror’s children will then be name-value tuples describing the original object’s properties”).
It would have been obvious for a person of an ordinary skilled in the art as of the effective filing date of the claimed invention to modify the teachings of Fan and Chouhan to incorporate the teaching of Neuburg. One would have been motivated to use Swift reflection in order to introspect code.
Per claim 15, Neuburg further teaches
wherein the matching code is Swift code (see at least page 290 “Introspection. Swift provides limited ability to introspect an object, letting an object display the names and values of its properties. This feature is intended for debugging, not for use in your program’s logic. For example, you can use it to modify the way your object is displayed in the Xcode Debug pane. To introspect an object, use it as the reflecting: parameter when you instantiate a Mirror. The Mirror’s children will then be name-value tuples describing the original object’s properties”).
Claims 16 and 17 are rejected under 35 U.S.C. 103 as being unpatentable over CN112241370A to Fan in view of U.S. Pub. No. 20160013989 to Chouhan and in further view of Kotlin in Action” to Jemerov.
Per claim 16, neither Fan or Chouhan teaches
wherein the reflection is a Kotlin reflection.
Jemerov teaches an analogous art relates to Kotlin reflection API, comprises:
a Kotlin reflection (see at least chapter 10.2.1 & 10.2.2 “The Kotlin reflection API: KClass, KCallable, KFunction, and KProperty… implementing object serialization using reflection…”).
It would have been obvious for a person of an ordinary skilled in the art as of the effective filing date of the claimed invention to modify the teachings of Fan and Chouhan to incorporate the teaching of Kotlin to use Kotlin reflection. One would have been motivated to use Kotlin reflection in order to implement Kotlin code.
Per claim 17, Jemerov further teaches
wherein the matching code is Kotlin code (see at least chapter 10.2.1 & 10.2.2 “The Kotlin reflection API: KClass, KCallable, KFunction, and KProperty…Implementing object serialization using reflection…”).
Response to Arguments
Applicant’s arguments with respect to claim 4 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
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to PHILLIP H NGUYEN whose telephone number is (571)270-1070. The examiner can normally be reached Monday-Friday 9:00AM-5:00PM.
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 Zhen can be reached at (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.
/PHILLIP H NGUYEN/Primary Examiner, Art Unit 2191