DETAILED ACTION
Statement of claims
The present application includes:
Claims 1-20 are pending in the application. Claims 1-20 are being considered on the merits.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 07/17/2024. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Jose et al (US 2020/0183710, Jose hereinafter) in view of Kewal Shah et al. “Analysis of Cross-Platform Mobile App Development Tools”, Mar 29-31, 2019, Kewal hereinafter).
As to claim 1, Jose teaches a method comprising:
detecting an activation of a feature of a mobile application to be operated on a computing device (e.g., see FIG. 1, “client device 120”, para 26, “a smartphone a smartphone, or the like. Client device 120 may execute an application 122” and “0027] Client device 120 may also host a shell framework (i.e., an application shell) (not shown in FIG. 1) which executes within the application 122.), the mobile application having a single programming component that includes platform-agnostic code for the feature (e.g., para 28, “ a user interface definition may include native user interface components, which may be specific to a platform, as well as platform-agnostic user interface components (e.g., web-based components)” and “widgets may be platform-agnostic and may include web-based widgets or framework-based widgets. A native widget may be built and implemented using code components that are native to the platform. For example, a native code component (e.g., a user interface component that is native to the platform) may be built using code components that are native to the operating system executing on the client device 120. Thus, the native code components can be executed directly by an application within the operating system, or executed as a stand-alone user interface component within the operating system” in para 43 .
[0044] A platform-agnostic widget may be built and implemented using platform-agnostic code components (e.g., non-native code components). A platform-agnostic code component may include, for example, a web-based code component that can be executed by a web browser (e.g., web widgets) or a framework-based code components that can be executed in a framework-based runtime environment (e.g., framework-based widgets). A platform-agnostic code component may be used to generate a user interface that can be shared across different platforms. Thus, platform-agnostic code components may allow a common user interface to be generated across multiple platforms.);
Translating the platform-agnostic code to platform-specific code corresponding to a programming platform of the computing device (e.g., para 91, “Once a platform-agnostic widget is loaded, the shell core 400 may hydrate the widget. “, “a web widget loaded into the shell core 400, the shell core 400 may translate the authentication from the application to into a representation to be used by the web browser in which the web widgets are executing. “. Thus, the “ representation” represents the platform-specific code) ; and
executing the feature of the mobile application on the computing device using the platform-specific code (e.g., para 45, “client device 120 can retrieve the identified user interface components from user interface component repository 170 or from user interface components deployed on the client device 120 based on whether the user interface components are platform-agnostic or platform-specific functionality.”).
However, Jose does not teach an interpreter; translating, using the interpreter.
Kewal teaches an interpreter; translating, using the interpreter, the platform-agnostic code to platform-specific code corresponding to a programming platform of the computing device (e.g., see pages 4 and 5, “C. Interpreted Apps:”, “Interpreted apps get their name from their ability to deploy the application source code directly to the mobile device where it is interpreted using a JavaScript engine.”, “Figure 3. A JavaScript engine or the Interpreter is also used along with the bridge to interact with the UI elements. React Native uses JavaScriptCore for iOS and V8 for Android as an interpreter.”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Jose with those of Kewal because both references are directed to related systems addressing similar technical problems within the same field and seek to improve system performance, reliability, and efficiency.
Jose et al. disclose detecting an activation of a feature of a mobile application to be operated on a computing device, the mobile application having a single programming component that includes platform-agnostic code for the feature while Kewal et al. teaches translating, using the interpreter, the platform-agnostic code to platform-specific code corresponding to a programming platform of the computing device; and executing the feature of the mobile application on the computing device using the platform-specific code.
Incorporating the teachings of Kewal et al. into the system of Jose et al. would have been a predictable and logical modification, yielding improved operational robustness and efficiency without requiring undue experimentation.
Such a combination would merely involve the substitution or integration of known elements performing their established functions, as taught by Kewal et al., into the system of Jose et al., consistent with design incentives and market demands for improved performance and scalability. Moreover, Kewal et al. explicitly recognize benefits to provide “user experience, stability of framework, ease of updating, cost of development and time to market an app.” (see Kewal, I. INTRODUCTION) . —that would naturally be desirable in the system of Jose et al.
Accordingly, to one of ordinary skill in the art would have had a reasonable expectation of success in combining Jose et al. with Kewal et al., and the combination represents no more than the predictable use of prior art elements according to their known functions.
As to claim 2, Jose teaches wherein the programming platform of the computing device is a first programming platform and the platform-specific code is written in a first programming language (e.g., para 50, wherein “code reuse across the shells 210, 220, and 230, platform-agnostic code (e.g., code written in JavaScript, PHP, or other languages that can be executed in various computing environments with similar execution results) may be used to implement the shells 210, 220, and 230” and “an application deployed via mobile shell 210 may integrate cross-platform user interface generation tools, native code components (e.g., Java components for applications deployed on Android devices or Objective C components for applications deployed on mobile device operating systems, such as iOS, Android, Windows Mobile, at the like)” in para 54. Thus, wherein the programming platform of the computing device is a first programming platform and the platform-specific code is written in a first programming language) .
As to claim 3, Jose teaches further wherein the platform-agnostic code is written in a second programming language corresponding to a development platform (para 50, wherein “code reuse across the shells 210, 220, and 230, platform-agnostic code (e.g., code written in JavaScript, PHP, or other languages that can be executed in various computing environments with similar execution results) may be used to implement the shells 210, 220, and 230” and “an application deployed via mobile shell 210 may integrate cross-platform user interface generation tools, native code components (e.g., Java components for applications deployed on Android devices or Objective C components for applications deployed on mobile device operating systems, such as iOS, Android, Windows Mobile, at the like)” in para 54. Thus, wherein the platform-agnostic code is written in a second programming language corresponding to a development platform). However, Jose does not teach the translating comprises: translating the second programming language to the first programming language using a framework of the interpreter. Kewal teaches the translating comprises: translating the second programming language to the first programming language using a framework of the interpreter (e.g., see page 5, “Flutter is an open source UI framework and mobile software development kit (SDK) created by Google that not only provides cross-platform support but also enhances the application performance”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Jose by adopting the teachings of Kewal to provide “user experience, stability of framework, ease of updating, cost of development and time to market an app.” (see Kewal, in I. INTRODUCTION).
As to claim 4, Jose teaches further wherein the first programming platform is one of Android or iOS (e.g., para 54, “an application deployed via mobile shell 210 may integrate cross-platform user interface generation tools, native code components (e.g., Java components for applications deployed on Android devices or Objective C components for applications deployed on mobile device operating systems, such as iOS, Android, Windows Mobile, at the like),”). However, Jose does not teach wherein the development platform is one of Flutter, React Native, or Xamarin. Kewal teaches wherein the development platform is one of Flutter, React Native (e.g., page 5, “Flutter runs its framework code and low-level engine code inside a lightweight Dart virtual machine.”, “Fig. 6. Architecture of a react native app”), or Xamarin .
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Jose by adopting the teachings of Kewal to provide “user experience, stability of framework, ease of updating, cost of development and time to market an app.” (see Kewal, in I. INTRODUCTION)
As to claim 5, Jose does not teach wherein the framework is a first framework associated with the first programming platform of the computing device, and the interpreter further includes at least a second framework associated with a second programming platform different from the first programming platform. However, Kewal teaches wherein the framework is a first framework associated with the first programming platform of the computing device, and the interpreter further includes at least a second framework associated with a second programming platform different from the first programming platform ( e.g., see page 3, “Fig. 3. Hybrid apps architecture [10]”, “the hybrid cross-platform tool takes care of that - translating API calls to suit the environment of the target platforms selected.” And “Fig. 5. A flow of events displaying an updated version of an app usingReact Native. [16]”, “C. Interpreted Apps:” in page 5).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Jose by adopting the teachings of Kewal to provide “user experience, stability of framework, ease of updating, cost of development and time to market an app.” (see Kewal, in I. INTRODUCTION)
As to claim 6, Jose does not teach wherein the interpreter includes a framework associated with each of at least two different programming platforms . However, Kewal teaches herein the interpreter includes a framework associated with each of at least two different programming platforms (e.g., see page 5, “the platform”, for iOS “, “ for Android.” , “to support cross-platform allows users to interact with the platform-specific user interface.”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Jose by adopting the teachings of Kewal to provide “user experience, stability of framework, ease of updating, cost of development and time to market an app.” (see Kewal, in I. INTRODUCTION)
As to claim 7, Jose teaches wherein the single programming component is embedded into primary code of the mobile application (e.g., para 29, “native code components can be referenced in a user interface definition to allow users to provide voice data into the application 122, engage in video chats with other users or with live support representatives using the application 122, etc. Further, native code components may be referenced in a user interface definition to enable a user to take advantage of input methods and technologies particular to a platform, such as a multi-touch and/or pressure-sensitive touchscreen display, etc.” and “The user interface definition interacts with underlying application logic (e.g., stored in application logic repository 180) that may be implemented as a single code base maintained independently from platform-specific code. Common application components need not be duplicated,” in para 37) .
As to claim 8, Jose teaches further comprising: obtaining the mobile application from a repository (e.g., para 37, “The user interface definition interacts with underlying application logic (e.g., stored in application logic repository 180) that may be implemented as a single code base maintained independently from platform-specific code. Common application components need not be duplicated,”).
As to claim 9, Jose does not explicitly teach wherein the mobile application is downloaded from the repository and installed on the computing device prior to detecting the activation of the feature. However, Kewal teaches wherein the mobile application is downloaded from the repository and installed on the computing device prior to detecting the activation of the feature (e.g., see page 3, “hybrid Apps”, “is installable on the client's device even though the data and logic for the program come from a remote server.” . Thus, wherein the mobile application is downloaded from the repository and installed on the computing device prior to detecting the activation of the feature).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Jose by adopting the teachings of Kewal to provide “user experience, stability of framework, ease of updating, cost of development and time to market an app.” (see Kewal, in I. INTRODUCTION)
As to claim 10., see rejection of claims 1 and 8 above .
As to claim 11, see rejection of claims 2and 3 above.
As to claim 12, 13-14, 16-17 see rejection of claims 4, 6 and 8-9 above .
As to claim 15, see rejection of claim 7 above .Jose teaches further wherein the single programming component is a library, and the library is embedded into primary code of the mobile application (e.g., para 49, “Each shell may be made available (e.g., via one or more data repositories) as a library that may be semantically versioned (e.g., versioned using a three part version number, such as 1.2.3, representing a major version, a minor version and a patch, respectively). Native mobile applications may consume the mobile shell 210 as a library and package the mobile shell 210 as part of the application”).
As to claim 18, see rejection of claims 1-3 Jose teaches further a non-transitory computer readable medium storing instructions for a mobile application comprising primary application code (e.g., para 7, “a system comprising a processor and a memory. The memory comprises executable instructions, which, when executed by the processor, cause the system to receive, from a server, a first workflow step definition including a first set of widgets to be loaded into an application shell.”) and a single programming component, including feature code for a feature of the mobile application and an interpreter, embedded into the primary application code, and the instructions, when executed by one or more processors, cause the one or more processors (e.g., para 7, “ instructions which, when executed by the processor, cause the system to identify that a first widget of the first set of widgets in the first workflow step definition is implemented using native code components.”) to:
receive an indication of an activation of the feature of the mobile application for operation on a computing device; invoking the single programming component to translate (e.g., para 7, “when executed by the processor, cause the system to identify that a second widget of the first set of widgets in the first workflow step definition is implemented using platform-agnostic code components. The memory further comprises instructions which, when executed by the processor, cause the system to load the second widget of the first set of widgets into the application shell via a platform-agnostic widget proxy service.”).
As to claim 19, see rejection of claim 6 above .
As to claim 20, see rejection of claim 3 above. Kewal teaches s further, wherein to translate, using the interpreter, the feature code, the one or more processors are further caused to: use framework code of a framework, from the one or more frameworks, associated with the programming platform of the computing device to translate the feature code ( e.g., see page 3, “the hybrid cross-platform tool takes care of that - translating API calls to suit the environment of the target platforms selected”).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify the method of Jose by adopting the teachings of Kewal to provide “user experience, stability of framework, ease of updating, cost of development and time to market an app.” (see Kewal, in I. INTRODUCTION)
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure
Blume et al. (US 9,218162) discloses A method for synthesizing mobile applications is provided. The method includes receiving a mobile application specification and compiling a first native mobile application based at least in part on the mobile application specification. A second native mobile application is then compiled based at least in part on the mobile application specification. The first native mobile application is sent to a first client device. The first native mobile application is specific to the first client device and the first native mobile application is capable of being executed by the first client device. The second native mobile application is sent to a second client device, the second native mobile application being specific to the second client device and the second native mobile application is capable of being executed by the second client device.
Nandakumat et al. (US 2017/0102976) discloses An OS API mapping computer operates to identify a set of OS APIs of a first OS version not present in a second OS version. OS APIs of the second OS version are identified that satisfy a defined rule for compatibility with the set of OS APIs of the first OS version not present in the second OS version. An OS APIs replacement list is generated that maps individual ones of the set of OS APIs of the first OS version, to corresponding ones of the OS APIs of the second OS version that satisfy the defined rule. A set is identified of OS APIs of an application that are in the OS APIs replacement list among the set of OS APIs of the first OS version. A plugin is generated based on the OS APIs of the second OS version mapped to the set of application OS APIs..
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDOU K SEYE whose telephone number is (571)270-1062. The examiner can normally be reached M-F 9-5:30.
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, Pierre Vital can be reached at 5712724215. 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.
/ABDOU K SEYE/Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198