DETAILED ACTION
The Office Action is in response to Amendments filed 11/25/2025.
Claims 1-2, 4-5, 7-11, and 14-18 are currently amended.
Claims 6 and 12 are cancelled.
Claims 1-5, 7-11, and 13-18 are currently pending.
The rejection of claims 1-5, 7-11, and 13-18 under 35 U.S.C. 112(b) are withdrawn in view of the applicant’s amendments to claims 1-2, 4-5, 7-11, and 14-18.
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 .
Drawings
The drawings are objected to because the unlabeled rectangular boxes shown in the drawings should be provided with descriptive text labels. Corrected drawing sheets in compliance with 37 CFR 1.121(d) are required in reply to the Office action to avoid abandonment of the application. Any amended replacement drawing sheet should include all of the figures appearing on the immediate prior version of the sheet, even if only one figure is being amended. The figure or figure number of an amended drawing should not be labeled as “amended.” If a drawing figure is to be canceled, the appropriate figure must be removed from the replacement sheet, and where necessary, the remaining figures must be renumbered and appropriate changes made to the brief description of the several views of the drawings for consistency. Additional replacement sheets may be necessary to show the renumbering of the remaining figures. Each drawing sheet submitted after the filing date of an application must be labeled in the top margin as either “Replacement Sheet” or “New Sheet” pursuant to 37 CFR 1.121(d). If the changes are not accepted by the examiner, the applicant will be notified and informed of any required corrective action in the next Office action. The objection to the drawings will not be held in abeyance.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-3, 8, and 14-18 are rejected under 35 U.S.C. 103 as being unpatentable over US 20230028638 A1 hereinafter “Seawall” in view of US 20220137944 A1 hereinafter “Patterson”.
With regards to claim 1, Patterson teaches
the method comprising the steps of:
creating sub-apps for each subsystem, wherein the sub-apps are specific to the measuring system of the second type; (Patterson [0039], “When the user input is a request for previously unused functionality of the particular application, i.e. corresponds to a request for install of one or more sub-packages providing a discrete set of functionality, the user input may be received while the particular application is executing at the computing device. When application installer 26 has received and/or obtained at least one application sub-package 24A-240 (collectively, “application sub-packages 24”) of application 18, application installer 26 may install application 18 at computing device 2. When the user input is a request for previously unused functionality of the particular application, the download and installation may be performed while the particular application is executing at the computing device. This on-the-fly approach to sub-package installation may improve utilization of resources of a mobile computing device without affecting user experience.”)
creating a multipart app (Patterson [0130], “By allowing the software developer to design an application with separate sub-packages for separate sets of functionality, application containers 102 may enable an application to execute at computing device 100 without all of its respective execution components for all of its sub-packages being locally resident on computing device 100. In this way, the initial execution of an application may not require the retrieval and/or installation of all sub-packages but rather only a subset of sub-packages that include executable components implementing the requested functionality.”) including all sub-apps; (Patterson [0032], “Applications 10 and 12 include sub-packages 20A-20N (collectively “sub-packages 20”) and sub-packages 22A-22M (collectively “sub-packages 22”), respectively. Each of sub-packages 20 and 22 are installable application sub-packages that provide discrete sets of functionality for applications 10 and 12.”)
splitting the multipart app; (Patterson [0129], “Computing device 100 includes functionality to support applications that are split into various application sub-packages, such as applications 10, 12, and 18 of FIG. 1, which include sub-packages 20, 22, and 24, respectively. A sub-package may include resources (e.g., images, text, videos or any other non-compiled data), security and/or signing information, version information and/or dependency information, or any other information for an application”)
receiving at each subsystem only its sub-app from the multipart app;(Patterson [0033], “While all of sub-packages 20 for application 10 collectively may be large in size, computing device 2 may retrieve, install, and execute only those sub-packages 20 necessary to provide functionality requested by a user. As such, when installing and/or executing application 10, only a portion of sub-packages 20 for application 10 need to reside locally at the computing device for application 10 to execute.”)
checking at each subsystem its version; (Patterson [0052], “In other words, the computing device 2 may receive, from the application provider, an indication of one or more application elements currently installed at the computing device which are to be reused during installation of the application 18. If necessary, application provider 6 may also send a patch to computing device 2 that may be used to update the application element of the application that is already installed at computing device 2, so that the application element, as patched, is the same as an application element of application elements. For example, the one or more application elements may include an application element that is to be updated from a current version to a different version required by the application 18 by applying the patch to the application element to generate a patched application element.”) and
installing the corresponding sub-app at the subsystem only if its version is needed. (Patterson [0061], “Application provider 6 may also generate a patch that will be applied by computing device 2 to the application element already installed in order to change the application element into the version of the application element required by application sub-package 24A. Application provider 6 compresses the patch and sends the patch to computing device 2 using one of the download streams established with computing device 2.”) [Examiner’s Note: A patch can be defined by retrieving only the sub-packages required in order to provide functionality requested by a user]
Patterson teaches the method but does not teach: converting a measuring system of a first type to a second type
wherein the measuring system includes at least two subsystems, including a sensor and an end application,
wherein each subsystem is designed to be app-capable such that the firmware of each subsystem is designed to receive, install, and execute apps,
However, in an analogous art Seawall teaches [A method for] converting a measuring system of a first type to a second type, (Seawall [0027], “In various implementations, the smart edge platform can: include onboard edge processing pipelines that can shared across multiple and/or different physical sensors (either integrated into, or externally connected to the platform); allow the onboard edge processing pipelines to be reused and/or adapted across different sensors, different groups of sensors, different applications of the smart sensor platform, and/or different platforms altogether; apply various navigation systems and data to group data; provide control over various sensor groups to a central control system (human-in-the-loop and/or automated software);”)
wherein the measuring system includes at least two subsystems, including a sensor and an end application, (Seawall [0029], “the smart edge platform includes an abstracted sensor driver that is connected to one or more internal and/or external sensors to receive sensor data and send sensor controls and is communicatively coupleable smart edge platform modules and interfaces, one or more communication component(s) that are communicatively coupleable to one or more external computing devices, at least one processor, and at least one memory. The residential user interface can be accessible to the user of one of the external computing device(s) via one of the communication component(s). The abstracted sensor driver communicates with the sensor(s) in a first format native to the sensor (internal or external); processes the sensor data, where the processing includes converting the sensor data from the first format to a second format; and forwards the processed sensor data to various other smart edge platform modules and interfaces (e.g., the residential user interface).”)
wherein each subsystem is designed to be app-capable such that the firmware of each subsystem is designed to receive, install, and execute apps, (Seawall [0035-37], “the one or more abstracted communication drivers components of the smart edge platform are communicatively coupleable to a remote server. In such implementations, the smart edge platform can instantiate two-way messaging with the remote server, two-way transfer of data with the remote server, receive system configuration and software updates from the remote server. A remote operations interface can then provide remote operators smart edge device coupleable display widgets, control widgets, data management tools, data post-processing tools, AI training tools, and smart sensor configuration and software updating tools. By providing a capability and means to update new software modules from the remote server- and install the processing module, the smart edge platform can accommodate new external sensors in an ad-hoc manner, install updates that improve the accuracy of the sensor data, and/or install updates that provide additional functionality to the smart edge platform using the sensor data … In some implementations, the edge software component can instantiate and/or control a robotic system interface that is operatively coupled to the actuatable system driver(s). In such implementations, the robotic system interface can provide a network-accessible interface that allows a user (local or remote) to control one or more robotic components that communicatively coupled to the smart edge platform.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Seawall into the teachings of Patterson. This combination of teachings would have resulted in a method configured to install a multipart application comprising multiple packages corresponding to system elements, as in Patterson, with the intent of updating a measurement system with subsystems to obtain the application accordingly, as in Seawall. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of supporting remote software management and configuration of the smart edge platform (Seawall [0057-58]).
With regards to claim 2, the rejection of claim 1 is incorporated.
Patterson further teaches wherein the multipart app is installed by a central system and is distributed to the subsystems. (Patterson [0053], “In this way, application provider 6 may send to computing device 2, and computing device 2 may receive from application provide 6, indications of the one or more application elements of application 18 that can be obtained from applications that are already installed at computing device 2, along with one or more patches that computing device 2 may apply to one or more application elements of the applications that are already installed at computing device 2, in order to obtain the one or more application elements of application 18 from the applications that are already installed at computing device 2.”) [Examiner’s Note: An application provider can be a central system that sends the application as the multipart app with patches accordingly to the application elements]
With regards to claim 3, the rejection of claim 2 is incorporated.
Patterson further teaches wherein the multipart app is split by the central system into the sub-apps and the sub-apps are transmitted to the respective subsystems. (Patterson [0032], “Applications 10 and 12 include sub-packages 20A-20N (collectively “sub-packages 20”) and sub-packages 22A-22M (collectively “sub-packages 22”), respectively. Each of sub-packages 20 and 22 are installable application sub-packages that provide discrete sets of functionality for applications 10 and 12 [wherein the multipart app is split by the central system into the sub-apps].”) (Patterson [0144], “Computing device 2 may receive a user input to install an application that is not currently installed at the computing device, wherein a plurality of applications are currently installed at the computing device, and wherein each of the plurality of applications includes a respective plurality of application elements …While this example is described as an initial install of application 18, the techniques may also be applied to the installation of a sub-package of an application already installed at computing device 2. For example, these techniques may be applied to the installation of sub-package 24B of application 18 where other application sub-packages of application 18 (e.g., sub-package 24A and 240) are already installed at computing device 2 [and the sub-apps are transmitted to the respective subsystems.].”)
With regards to claim 8, the rejection of claim 1 is incorporated.
Patterson further teaches wherein the sub-app of the subsystem on which the multipart app has been installed is installed on the subsystem (Patterson [0136], “Application provider 6 may also generate a patch that will be applied by computing device 100 to the application element in order to change the application element into the version of the application element required by the application sub-package. Application provider 6 compresses the patch and sends the patch to computing device 2 using one of the download streams established with computing device 100. Application provider 6 also sends the stripped version of the application sub-package to computing device 100 using another one of the download streams established with computing device 100.”)
With regards to claim 14, the rejection of claim 1 is incorporated.
Patterson does not teach: wherein each sub-app comprises at least one of the following tasks: signal-processing, user interface for configuration and interaction, visualization, data transformation to a superordinate system
However, in an analogous art Seawall teaches wherein each sub-app comprises at least one of the following tasks: signal-processing, user interface for configuration and interaction, visualization, data transformation to a superordinate system (Seawall [0028], “Additionally, or alternatively, the smart edge platform can address common needs and/or challenges of typical robotics-integrated sensor platforms by connecting the abstracted sensor and control interfaces with onboard functionalities. For example, the smart edge platform can include an edge processing management system that connects abstracted sensor data streams to one or more onboard processing routines. In some implementations, the onboard processing routines are real-time modules that are selectable from a stored library of routines. The smart edge platform can also include a navigation and pose management system that associates sensor data with orientation and position data. In various implementations, the orientation and position data can be fixed, from an onboard orientation and position sensor, and/or from an external source (e.g., from an external global positioning system (GPS) sensor). The smart edge platform can also include a storage system that stores time-synchronized sensor data, edge processing data, navigation data, orientation data, and/or system status data. In various implementations, the storage system can store the data at set intervals, based on one or more predefined externally or internally detected events, and/or continuously. The smart edge platform can also include a RUI that hosts an internet service allowing platform users to manage and/or monitor the smart edge system and/or the smart edge platform (and any connected systems) through an internet browser from any suitable remote electronic device (e.g., a user's a mobile phone; smartphone; handheld device; PDS; tablet; notebook, Ultrabook, and/or laptop computer; e-reader; desktop computer; wearable device; etc.). Because the smart edge platform is accessible through the internet browser, no special software needs to be installed to manage and/or monitor the smart edge platform. The smart edge platform can also include an IoT Interface allowing one or more remote devices to communicate, monitor, and/or control the smart edge system and/or the smart edge platform.”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Seawall into the teachings of Patterson. This combination of teachings would have resulted in a method configured to install a multipart application comprising multiple packages corresponding to system elements, as in Patterson, with the intent of updating a measurement system with subsystems to obtain the application accordingly, as in Seawall. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of supporting remote software management and configuration of the smart edge platform (Seawall [0057-58]).
With regards to claim 16, the rejection of claim 15 is incorporated.
Patterson does not teach the measuring system comprises the sensor, measuring transducer, edge device, cloud, and end application subsystems.
However, in an analogous art Seawall teaches the measuring system comprises the sensor, measuring transducer, edge device, cloud, and end application subsystems. (Seawall [0060], “In various implementations, the sensor can include image sensors (e.g., CMOS sensors, 3D sensors, LIDAR sensors, etc.), orientation sensors, position sensors, local environment sensors (e.g., temperature sensors, flow rate sensors, pressure sensors, etc.), and the like. Varying sensor types can be based on varying native formats. Instead of requiring hardware updates to handle the varying formats, however, the edge module 404 can accommodate the varying formats, thereby providing an abstracted pathway that allows sensors to be added as required. When a new sensor is added, the edge module 404 can connect to the sensor and/or be updated if needed to connect to the sensor [measuring system comprises the sensor, measuring transducer, edge device]. Once connected, as discussed above, the edge module 404 can provide information from the downstream component 406 to the sensor. The information can include configuration options such as enabling/disabling one or more sensors, setting sensor rates, ranges, angles, resolutions, and intensities, and the like.”) (Seawall [0076], “The edge component 710 can include all of the smart edge platforms, and the components thereof, discussed above. For example, the edge component 710 can include various onboard modules related to receiving and/or processing sensor data; onboard modules related to controlling the smart edge platform, any sensors integrated with and/or coupled to the smart edge platform, and/or any actuatable components integrated with and/or coupled to the smart edge platform; onboard data storage modules; and/or various software management systems. The remote component 750 can include a remote server (e.g., a cloud-based server, network-accessible server, and the like) [cloud, and end application subsystems]. The remote component can store additional modules that can be deployed on the edge component 710;”)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Seawall into the teachings of Patterson. This combination of teachings would have resulted in a method configured to install a multipart application comprising multiple packages corresponding to system elements, as in Patterson, with the intent of updating a measurement system with subsystems to obtain the application accordingly, as in Seawall. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of supporting remote software management and configuration of the smart edge platform (Seawall [0057-58]).
Claim 15 is directed to a measuring system corresponding to the method limitations as disclosed in claim 1. Thus, claim 15 is rejected for the same reasons set forth in claim 1.
Claim 17 is directed to a non-transitory computer readable storage medium corresponding to the system limitations as disclosed in claim 1. Thus, claim 17 is rejected for the same reasons set forth in claim 1.
Claim 18 is directed to a non-transitory computer readable storage medium corresponding to the system limitations as disclosed in claim 16. Thus, claim 18 is rejected for the same reasons set forth in claim 16.
Claims 4-5 and 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Patterson in view of Seawall, as applied to claim 1, and further in view of US 8589541 B2 hereinafter “Raleigh”.
With regards to claim 4, the rejection of claim 2 is incorporated.
The combination of Patterson and Seawall teaches wherein the multipart app is transmitted from the central system to a first subsystem of the at least two subsystems but does not teach: [wherein the multipart app is transmitted from the central system to a first subsystem of the at least two subsystems,] the first subsystem installs its sub-app, and forwards the multipart app to a second subsystem of the at least two subsystems, where the respective sub-app is then installed.
However, in an analogous art Raleigh teaches […] the first subsystem installs its sub-app, and forwards the multipart app to a second subsystem of the at least two subsystems, where the respective sub-app is then installed. (Raleigh Column 94 Lines 53-67, In some embodiments, classifying the network service usage activity further includes classifying the network service usage activity based on one or more of the following: application or widget (e.g., Outlook, Skype, iTunes, Android email, weather channel weather widget, iCal, Firefox Browser, etc), application type (e.g., user application, system application/utility/function/process, OS application/utility/function/process, email, browser, widget, malware (such as a virus or suspicious process), RSS feed, device synchronization service, download application, network backup/imaging application, voice/video chat, peer to peer content application or other peer to peer application, streaming media feed or broadcast reception/transmission application, network meeting application, chat application or session, and/or any other application or process identification and categorization)”) [Examiner’s Note: A peer to peer communication means to share, transmit, and receive the same application amongst peers/subsystems which could be in a chronological order of installation as well]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Raleigh into the teachings of Patterson in view of Seawall. This combination of teachings would have resulted in a method configured to install a multipart application comprising multiple packages corresponding to system elements, as in Patterson, with the intent of updating a measurement system with subsystems to obtain the application accordingly, as in Seawall, the installation occurring sequentially over a peer-to-peer communication, as in Raleigh. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of conserving network transmission bandwidth of persistent traffic by controlling access to resources (Raleigh Column 15 Lines 5-18).
With regards to claim 5, the rejection of claim 4 is incorporated.
The combination of Patterson and Seawall does not teach wherein the first subsystem forwards only a non-installed part.
However, in an analogous art Raleigh teaches wherein the first subsystem forwards only a non-installed part. (Raleigh Columns 64-65 Lines 64-67 and 1-29, “For example, it can be preferable in some embodiments to reduce the inter-agent communication required to track or trace a packet through the stack processing by assigning a literal tag so that each flow or packet has its own activity association embedded in the data. As another example, it can be preferable in some embodiments to re-use portions of standard communication stack software or components, enhancing the verifiable traffic control or service control capabilities of the standard stack by inserting additional processing steps associated with the various service agents and monitoring points rather than re-writing the entire stack to correctly process literal tagging information, and in such cases, a virtual tagging scheme may be desired. As yet another example, some standard communication stacks provide for unused, unspecified or otherwise available bit fields in a packet frame or flow, and these unused, unspecified or otherwise available bit fields can be used to literally tag traffic without the need to re-write all of the standard communication stack software, with only the portions of the stack that are added to enhance the verifiable traffic control or service control capabilities of the standard stack needing to decode and use the literal tagging information encapsulated in the available bit fields …In some embodiments, the manner in which the virtual or literal tagging is implemented can be developed into a communication standard specification so that various device or service product developers can independently develop the communication stack and/or service processor hardware and/or software in a manner that is compatible with the service controller specifications and the products of other device or service product developers.”) [Examiner’s Note: Unused bits fields can be passed along in order to communicate unused data that can configure communication amongst peers]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Raleigh into the teachings of Patterson in view of Seawall. This combination of teachings would have resulted in a method configured to install a multipart application comprising multiple packages corresponding to system elements, as in Patterson, with the intent of updating a measurement system with subsystems to obtain the application accordingly, as in Seawall, the installation occurring sequentially over a peer-to-peer communication, as in Raleigh. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of conserving network transmission bandwidth of persistent traffic by controlling access to resources (Raleigh Column 15 Lines 5-18).
With regards to claim 10, the rejection of claim 1 is incorporated.
The combination of Patterson and Seawall does not teach: wherein the multipart app is transmitted from the subsystem on which the multipart app was installed to a further subsystem, this subsystem installs its sub-app, and forwards the multipart app to another subsystem, where the respective sub-app is then installed.
However, in an analogous art Raleigh teaches wherein the multipart app is transmitted from the subsystem on which the multipart app was installed to a further subsystem, this subsystem installs its sub-app, and forwards the multipart app to another subsystem, where the respective sub-app is then installed. (Raleigh Column 94 Lines 53-67, In some embodiments, classifying the network service usage activity further includes classifying the network service usage activity based on one or more of the following: application or widget (e.g., Outlook, Skype, iTunes, Android email, weather channel weather widget, iCal, Firefox Browser, etc), application type (e.g., user application, system application/utility/function/process, OS application/utility/function/process, email, browser, widget, malware (such as a virus or suspicious process), RSS feed, device synchronization service, download application, network backup/imaging application, voice/video chat, peer to peer content application or other peer to peer application, streaming media feed or broadcast reception/transmission application, network meeting application, chat application or session, and/or any other application or process identification and categorization)”) [Examiner’s Note: A peer to peer communication means to share, transmit, and receive the same application amongst peers/subsystems which could be in a chronological order of installation as well]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Raleigh into the teachings of Patterson in view of Seawall. This combination of teachings would have resulted in a method configured to install a multipart application comprising multiple packages corresponding to system elements, as in Patterson, with the intent of updating a measurement system with subsystems to obtain the application accordingly, as in Seawall, the installation occurring sequentially over a peer-to-peer communication, as in Raleigh. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of conserving network transmission bandwidth of persistent traffic by controlling access to resources (Raleigh Column 15 Lines 5-18).
With regards to claim 11, the rejection of claim 10 is incorporated.
The combination of Patterson and Raleigh does not teach: wherein the respective subsystem forwards only a non-installed part.
However, in an analogous art Raleigh teaches wherein the respective subsystem forwards only a non-installed part. (Raleigh Columns 64-65 Lines 64-67 and 1-29, “For example, it can be preferable in some embodiments to reduce the inter-agent communication required to track or trace a packet through the stack processing by assigning a literal tag so that each flow or packet has its own activity association embedded in the data. As another example, it can be preferable in some embodiments to re-use portions of standard communication stack software or components, enhancing the verifiable traffic control or service control capabilities of the standard stack by inserting additional processing steps associated with the various service agents and monitoring points rather than re-writing the entire stack to correctly process literal tagging information, and in such cases, a virtual tagging scheme may be desired. As yet another example, some standard communication stacks provide for unused, unspecified or otherwise available bit fields in a packet frame or flow, and these unused, unspecified or otherwise available bit fields can be used to literally tag traffic without the need to re-write all of the standard communication stack software, with only the portions of the stack that are added to enhance the verifiable traffic control or service control capabilities of the standard stack needing to decode and use the literal tagging information encapsulated in the available bit fields …In some embodiments, the manner in which the virtual or literal tagging is implemented can be developed into a communication standard specification so that various device or service product developers can independently develop the communication stack and/or service processor hardware and/or software in a manner that is compatible with the service controller specifications and the products of other device or service product developers.”) [Examiner’s Note: Unused bits fields can be passed along in order to communicate unused data that can configure communication amongst peers]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Raleigh into the teachings of Patterson in view of Seawall. This combination of teachings would have resulted in a method configured to install a multipart application comprising multiple packages corresponding to system elements, as in Patterson, with the intent of updating a measurement system with subsystems to obtain the application accordingly, as in Seawall, the installation occurring sequentially over a peer-to-peer communication, as in Raleigh. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of conserving network transmission bandwidth of persistent traffic by controlling access to resources (Raleigh Column 15 Lines 5-18).
Claims 7 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Patterson in view of Seawall as applied to claim 1 above, and further in view of US 20190065173 A1 hereinafter “Xi”.
With regards to claim 7, the rejection of claim 1 is incorporated.
The combination of Patterson and Seawall does not teach: the installation takes place using a memory card.
However, in an analogous art Xi teaches the installation takes place using a memory card (Xi [0094], "A removable mass storage device 512 provides additional data storage capacity for the computer system 500, and is coupled either bi-directionally (read/write) or unidirectionally (read only) to processor 502. For example, storage 512 can also include computer-readable media such as magnetic tape, flash memory, PC-CARDS, portable mass storage devices, holographic storage devices, and other storage devices [using a memory card]. A fixed mass storage 520 can also, for example, provide additional data storage capacity. The most common example of mass storage 520 is a hard disk drive. Mass storage device 512 and fixed mass storage 520 generally store additional programming instructions [the installation takes place], data, and the like that typically are not in active use by the processor 502. It will be appreciated that the information retained within mass storage device 512 and fixed mass storage 520 can be incorporated, if needed, in standard fashion as part of memory 510 (e.g., RAM) as virtual memory.")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Xi into the teachings of Patterson in view of Seawall. This combination of teachings would have resulted in a method configured to install a multipart application comprising multiple packages corresponding to system elements, as in Patterson, with the intent of updating a measurement system with subsystems to obtain the application accordingly, as in Seawall, wherein the measurement device contains plug-ins that can be combined into an installable application to the system for updated functionality, as in Xi. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of configuring a mobile device using a plugin installation package that can be user defined according to user preferences and requirements (Xi [0026-27]).
With regards to claim 13, the rejection of claim 1 is incorporated.
The combination of Patterson and Seawall does not teach wherein the multipart app comprises more sub-apps than there are subsystems
However, in an analogous art Xi teaches the multipart app comprises more sub-apps than there are subsystems. (Xi [0040], "In some embodiments, multiple plugins corresponding to the same app can be allocated with the same process identifier during execution. Plugins with the same process identifier can access each other's resources (e.g., memory, database, etc.) during execution. Take the example of an app plugin adapted to an Android operating system, each process is assigned an identifier by the operating system. This process identifier is referred to as a UserID. By setting one identifier (UserID) for different app plugins of the same app, a multi-plugin installation package (e.g., Android Package (APK)) having a single UserID can run in a single process. In other words, a multi-plugin APK having a single UserID can run in a single process, and within this single process the multiple app plugins can access resources (e.g., databases and files under the data directory) of any of the other app plugins in the multi-plugin APK.") [Examiner's Note: A subsystem can be interpreted as a process comprising multiple plugins. A multipart app with multiple processes will have more plugins than processes/subsystems]
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Xi into the teachings of Patterson in view of Seawall. This combination of teachings would have resulted in a method configured to install a multipart application comprising multiple packages corresponding to system elements, as in Patterson, with the intent of updating a measurement system with subsystems to obtain the application accordingly, as in Seawall, wherein the measurement device contains plug-ins that can be combined into an installable application to the system for updated functionality, as in Xi. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of configuring a mobile device using a plugin installation package that can be user defined according to user preferences and requirements (Xi [0026-27]).
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Patterson in view of Seawall as applied to claim 1 above, and further in view of US 20070214454 A1 hereinafter “Edwards”.
With regards to claim 9, the rejection of claim 1 is incorporated.
The combination of Patterson and Seawall teaches the multipart app is split by the subsystem on which the multipart app was installed into the sub-apps but does not teach [The multipart app is split by the subsystem on which the multipart app was installed into the sub-apps] and the sub-apps are transmitted to the respective other subsystems
However, in an analogous art Edwards teaches […] and the sub-apps are transmitted to the respective other subsystems (Edwards [0065], "Another embodiment of the present invention is directed at features involving the noted launcher software component. In particular, the launcher may serve as (i) an aggregator, or framework, to manage, present, launch and close all plugins; (ii) a single-point of common data entry, retrieval and management such as the user profile; (iii) a resource for routines and features that are common to channels, such as an auto-update scheduling mechanism; (iv) a common interface between the wireless device 120 and the data service provider 110 to assist in the management of the communications between them; (v) a centralized location for communications and/or transactions (e.g., e-commerce) with the user; and/or (vi) a mechanism to update some or all of the software components on the wireless device 120, including updating existing plugins/channels, adding new plugins/channels, removing old plugins/channels, and/or implementing new features [and is distributed from there to the other respective subsystems]. In this regard, the launcher may communicate with the plugins/channels through any number of application program interfaces (API).")
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have incorporated the teachings of Edwards into the teachings of Patterson in view of Seawall. This combination of teachings would have resulted in a method configured to install a multipart application comprising multiple packages corresponding to system elements, as in Patterson, with the intent of updating a measurement system with subsystems to obtain the application accordingly, as in Seawall, and forwarding the installable application amongst first and second subsystems wherein the first and second subsystems will install their respective plugins, as in Edwards. One of ordinary skill in the art would have been motivated to combine these teachings for the purpose of linking multiple applications by exchanging data in order to enhance the operation and capabilities of the wireless device without having to re-retrieve data from a service provider (Edwards [0064]).
Response to Arguments
Applicant’s arguments with respect to claims 1-5, 7-11, and 13-18 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
THIS ACTION IS MADE FINAL. 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 TRAVIS VIET TRAN whose telephone number is (571)272-3720. The examiner can normally be reached Monday-Friday 8:30AM-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, Wei Mui 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.
/T.V.T./ Examiner, Art Unit 2191
/WEI Y MUI/ Supervisory Patent Examiner, Art Unit 2191