DETAILED ACTION
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 claims filed on 07/29/2026.
Claims 1-8 and 11-13 are pending.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-7, and 11-12 are rejected under 35 U.S.C. 103 as being unpatentable over Kölhi (US 2024/0259640 A1) in view of Faulhaber (US 2019/0155633 A1) in view of Bruno (US 2010/0262959 A1).
With regard to claim 1, Kölhi teaches:
A program management system comprising: a program storage system; “In this embodiment, however, the AI model object recognition module is not located at user device 106. Instead, object recognition AI model server 110 (program storage system) transmits 200, via network 104 or via another network or data connection (e.g., a LAN, a mobile broadband network, etc.), one or more classification models to a server-side AI model object recognition module 202” [Kölhi ¶ 43].
and a user system, “Transceiver circuitry 506 transmits 508 the media stream to control circuitry 510, where it is received using media processing circuitry 512. Control circuitry 510 may be based on any suitable processing circuitry and comprises control circuitry and memory circuitry, which may be disposed on a single integrated circuit or may be discrete components” [Kölhi ¶ 47, fig. 5 Examiner notes, the control circuity 510 and all that it comprises is considered the user system].
wherein the program storage system includes: at least one processor; “In this embodiment, however, the AI model object recognition module is not located at user device 106. Instead, object recognition AI model server 110 transmits 200, via network 104 or via another network or data connection (e.g., a LAN, a mobile broadband network, etc.), one or more classification models to a server-side AI model object recognition module 202” [Kölhi ¶ 43].
and at least one memory device storing instructions which, when executed by the at least one processor, causes the at least one processor to perform operations including: “In this embodiment, however, the AI model object recognition module is not located at user device 106. Instead, object recognition AI model server 110 transmits 200, via network 104 or via another network or data connection (e.g., a LAN, a mobile broadband network, etc.), one or more classification models to a server-side AI model object recognition module 202” [Kölhi ¶ 43]. “Classification models database 524 may be located in a memory of media server 500, or may be located in one or more remote servers. Classification models database 524 transmits 526 the requested classification models to media server 500. Transceiver circuitry 506 receives the classification models and transmits 528 the classification models to memory 530” [Kölhi ¶ 49].
storing the program; “Classification models database 524 may be located in a memory of media server 500, or may be located in one or more remote servers. Classification models database 524 transmits 526 the requested classification models to media server 500” [Kölhi ¶ 49].
receiving a transmission request for the program “Media processing circuitry 512 identifies a type of the media content and transmits 520 a request for appropriate classification models to transceiver circuitry 506. Transceiver circuitry 506 transmits 522 the request to classification models database 524” [Kölhi ¶ 49].
and transmitting the program to the user system in response to a reception of the transmission request, “User device 106 may also use AI/ML classification models to identify objects in the media stream. Object recognition AI model server 110 (program storage system) may transmit 112 one or more classification models to user device 106” [Kölhi ¶ 42]. “Classification models database 524 transmits 526 the requested classification models to media server 500. Transceiver circuitry 506 receives the classification models and transmits 528 the classification models to memory 530” [Kölhi ¶ 49].
“The one or more classification models may be received from a server via a separate transmission from that of the media stream” [Kölhi ¶ 21].
the user system includes: at least one processor; “As referred to herein, processing circuitry should be understood to mean circuitry based on one or more microprocessors, microcontrollers, digital signal processors, programmable logic devices, filed-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), etc., and may include a multi-core processor (e.g., dual-core, quad-core, hexa-core, or any suitable number of cores)” [Kölhi ¶ 47].
and at least one memory device storing instructions which, when executed by the at least one processor, causes the at least one processor to perform operations including: “Control circuitry 510 may be based on any suitable processing circuitry and comprises control circuitry and memory circuitry, which may be disposed on a single integrated circuit or may be discrete components” [Kölhi ¶ 47].
receiving the program from the program storage system; “Classification models database 524 transmits 526 the requested classification models to media server 500. Transceiver circuitry 506 receives the classification models and transmits 528 the classification models to memory 530” [Kölhi ¶ 49]. “Memory 530 transmits 532 the classification models to media processing circuitry 512. Media processing circuitry 512 uses the classification models to identify objects within the media stream” [Kölhi ¶ 50].
entering the input data into the program; “Transceiver circuitry 606 also transmits 614 the media stream (input data) to media processing circuitry 616” [Kölhi ¶ 53]. “Memory 530 transmits 532 the classification models to media processing circuitry 512. Media processing circuitry 512 uses the classification models to identify objects within the media stream” [Kölhi ¶ 50].
obtaining an output from the program when the input data is entered into the program; “Memory 530 transmits 532 the classification models to media processing circuitry 512. Media processing circuitry 512 uses the classification models to identify objects within the media stream … Metadata describing each identified object is then transmitted 534 to metadata output circuitry 536” [Kölhi ¶ 50].
Kölhi fails to explicitly teach storing input data to be entered into the program; and deleting the program from the user system.
However, Faulhaber teaches:
storing input data to be entered into the program; “The user may upload training data 1016 to the provider network 199 (or cause the provider network 199 to obtain the training data) at circle '1 ', which may be stored in a storage location (e.g., a storage "bucket" of storage virtualization service 1002)), and can issue a request to begin the training process (not illustrated), and thus the container 1012 is run in the model training system 120 at circle '2' based on the container image 1011” [Faulhaber ¶ 126].
and deleting the program from the user system, “In some embodiments, the user, via the user device 102, can transmit a request to the model training system 120 to stop the machine learning model training process. The model training system 120 can then instruct the virtual machine instance 122 to delete the ML training container 130 and/or to delete any model data stored in the training model data store 175” [Faulhaber ¶ 48].
Faulhaber is considered to be analogous to the claimed invention because it is in the same field of program loading. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kölhi to incorporate the teachings of Faulhaber and include: storing input data to be entered into the program; and deleting the program from the user system. Doing so would allow for users to enter input to the program in real time utilizing the stored data. “Thus, a client application 1008, via API requests (e.g., HTTP requests carrying an "InvokeEndpoint" call) issued to inference endpoints 1010 (e.g., at circle '7B'), can issue requests to use the model to perform an inference (e.g., in substantially "real time" as an "online" system). Additionally or alternatively, one or more inferences may be performed using inference input data 1050 (e.g., one inference, multiple inferences performed as a "batch", etc.) shown at circle '7A' stored in storage virtualization service 1002, and thus the request may include an identifier of inference input data 1050” [Faulhaber ¶ 150].
Kölhi in view of Faulhaber fails to explicitly teach receiving a program from a developer client used by a developer of the program; receiving a transmission request for the program from a user of the user system who is different from the developer; and deleting the program from the user system upon receiving a delete instruction associated with the program from the developer client, wherein the developer client cannot access the user system.
However, Bruno teaches:
receiving a program from a developer client used by a developer of the program; “For example, some programs may be provided by third-party software developers and/or vendors, either affiliated with or not affiliated with a specific mobile operator. Such developers and/or vendors may submit applications, updates, revocations, for inclusion on the mobile device application server 116 via a developer console 138 that may be provided, for example, as a part of a software development kit provided by the operator of the mobile device application server 116, by a mobile operator, etc” [Bruno ¶ 21].
receiving a transmission request for the program from a user of the user system who is different from the developer; “Such applications may be provided by an Internet-connected service provider, such as a mobile service provider, mobile device manufacturer, mobile device software manufacturer, and/or third party, via an application server that acts as an "application store" from which users can download applications, sometimes for a fee. In some situations, it may be wished to revoke an application that is currently available to users and has previously been downloaded by one or more users” [Bruno ¶ 1-2]. “For example, such instructions may be executable to communicate with mobile devices 102, 104, 106 over the mobile network 108 and WAN 114 to provide applications, to synchronize state, revoke applications, etc.; to communicate with the database 118 to execute search queries and communicate search results to the mobile devices 102, 104 106; and to perform various other functions and operations, including but not limited to those described herein” [Bruno ¶ 17]. “End-users of the mobile devices 102, 104, 106 also may be able to load applications onto a mobile device in ways other than during a communication session with the application server 116. For example, a removable media storage device, such as a flash memory drive or the like, may be used to side load an application onto a mobile device” [Bruno ¶ 19].
and deleting the program from the user system upon receiving a delete instruction associated with the program from the developer client, “For example, some programs may be provided by third-party software developers and/or vendors, either affiliated with or not affiliated with a specific mobile operator. Such developers and/or vendors may submit applications, updates, revocations, for inclusion on the mobile device application server 116 via a developer console 138 that may be provided, for example, as a part of a software development kit provided by the operator of the mobile device application server 116, by a mobile operator, etc” [Bruno ¶ 21]. “For example, as depicted in FIG. 2, the revocation instruction may be received from a vendor or developer 204, for example, if a flaw or bug is discovered in an application” [Bruno ¶ 26]. “Continuing with method 200, after receiving the application revocation request, an application revocation instruction is sent, at 212, to one or more mobile devices on which the revoked application is stored … Further, the revocation instruction may be configured to cause the selected application to be deleted from storage on the mobile device, or may be configured to mark the selected application as blacklisted, but allow it to remain in storage” [Bruno ¶ 29].
wherein the developer client cannot access the user system. “For example, some programs may be provided by third-party software developers and/or vendors, either affiliated with or not affiliated with a specific mobile operator. Such developers and/or vendors may submit applications, updates, revocations, for inclusion on the mobile device application server 116 via a developer console 138 that may be provided, for example, as a part of a software development kit provided by the operator of the mobile device application server 116, by a mobile operator, etc” [Bruno ¶ 21].
Bruno is considered to be analogous to the claimed invention because it is in the same field of program loading. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kölhi in view of Faulhaber to incorporate the teachings of Bruno and include: receiving a program from a developer client used by a developer of the program; receiving a transmission request for the program from a user of the user system who is different from the developer; and deleting the program from the user system upon receiving a delete instruction associated with the program from the developer client, wherein the developer client cannot access the user system. Doing so would allow a developer to cause the removal of flawed programs from users. “For example, as depicted in FIG. 2, the revocation instruction may be received from a vendor or developer 204, for example, if a flaw or bug is discovered in an application” [Bruno ¶ 26].
With regard to claim 2, Kölhi in view of Faulhaber in view of Bruno teaches the program management system according to claim 1, as referenced above. Kölhi further teaches transmitting the program includes transmitting the program associated with the location data to the user system, “Classification models database 524 transmits 526 the requested classification models to media server 500. Transceiver circuitry 506 receives the classification models and transmits 528 the classification models to memory 530” [Kölhi ¶ 49].
Kölhi fails to explicitly teach wherein receiving the transmission request includes receiving the transmission request associated with location data indicating a location of the input data, the program associated with the location data and the input data is obtained from a location indicated in the location data.
However, Faulhaber teaches:
wherein receiving the transmission request includes receiving the transmission request associated with location data indicating a location of the input data, “The user devices 102 can interact with the model training system 120 via frontend 129 of the model training system 120. For example, a user device 102 can provide a training request to the frontend 129 that includes a container image (or multiple container images, or an identifier of one or multiple locations where container images are stored), an indicator of input data (e.g., an address or location of input data) …” [Faulhaber ¶ 29].
the program associated with the location data “In some embodiments, the algorithm is pre-generated and obtained by a user, via the user device 102, from an algorithm repository (e.g., a network-accessible marketplace, a data store provided by a machine learning training service, etc.). In some embodiments, the algorithm is completely user-generated or partially user-generated (e.g., user-provided code modifies or configures existing algorithmic code)” [Faulhaber ¶ 30].
and the input data is obtained from a location indicated in the location data. “Prior to beginning the training process, in some embodiments, the model training system 120 retrieves training data from the location indicated in the training request. For example, the location indicated in the training request can be a location in the training data store 160. Thus, the model training system 120 retrieves the training data from the indicated location in the training data store 160. In some embodiments, the model training system 120 does not retrieve the training data prior to beginning the training process” [Faulhaber ¶ 39].
With regard to claim 3, Kölhi in view of Faulhaber in view of Bruno teaches the program management system according to claim 1, as referenced above. Kölhi further teaches wherein transmitting the program includes transmitting a program selected from a plurality of programs to the user system. “A first content type of a first media stream being output is determined, and at least one first classification model is selected based on the first content type” [Kölhi ¶ 27]. “A second content type of the second media stream is then determined and at least one second classification model is selected based on the second content type” [Kölhi ¶ 27]. “Select at least one different classification model” [Kölhi Fig. 12].
With regard to claim 4, Kölhi in view of Faulhaber in view of Bruno teaches the program management system according to claim 1, as referenced above. Kölhi further teaches:
wherein the operations performed by the user system further include: receiving a transmission request for the program from a user client; “If executed at a media server, control circuitry 510 of media server 500 may receive a request from a client device to which it is transmitting the first media stream for a second media stream” [Kölhi ¶ 86]. “At 702, the control circuitry accesses a media stream. When executed at a media server, control circuitry 510 of media server 500 may access a media source (e.g., media source 504) from which media assets are available. Control circuitry 510 may receive a request for specific media asset from a user device (e.g., client device 600) and access a media source from which the requested media asset is available” [Kölhi ¶ 57].
and transmitting a transmission request of the program to the program storage system in response to a reception of the transmission request from the user client, wherein the program storage system receives the transmission request from the user system. “Media processing circuitry 512 identifies a type of the media content and transmits 520 a request for appropriate classification models to transceiver circuitry 506. Transceiver circuitry 506 transmits 522 the request to classification models database 524” [Kölhi ¶ 49].
With regard to claim 5, Kölhi in view of Faulhaber in view of Bruno teaches the program management system according to claim 4, as referenced above. Kölhi further teaches the user system transmits a transmission request of the program to the program storage system without transmitting the location data to the program storage system, “Media processing circuitry 616 identifies a type of the media content and transmits 618 a request for appropriate classification models to transceiver circuitry 606. Transceiver circuitry 606 transmits 620 the request to classification models database 622. Classification models database 622 may be located in a memory of media server 600, or may be located in one or more other remote servers” [Kölhi ¶ 53 Examiner notes Kölhi does not explicitly recite location data at all and further does not recite transmitting input data to the storage system].
Kölhi fails to explicitly teach wherein the user system receives the transmission request, which is associated with location data indicating a location of the input data, from the client, and the input data is obtained from a location indicated in the location data.
However, Faulhaber teaches:
wherein the user system receives the transmission request, which is associated with location data indicating a location of the input data, from the client, “The user devices 102 (client) can interact with the model training system 120 (user system) via frontend 129 of the model training system 120. For example, a user device 102 can provide a training request to the frontend 129 that includes a container image (or multiple container images, or an identifier of one or multiple locations where container images are stored), an indicator of input data (e.g., an address or location of input data) …” [Faulhaber ¶ 29].
and the input data is obtained from a location indicated in the location data. “Prior to beginning the training process, in some embodiments, the model training system 120 retrieves training data from the location indicated in the training request. For example, the location indicated in the training request can be a location in the training data store 160. Thus, the model training system 120 retrieves the training data from the indicated location in the training data store 160. In some embodiments, the model training system 120 does not retrieve the training data prior to beginning the training process” [Faulhaber ¶ 39].
With regard to claim 6, Kölhi in view of Faulhaber in view of Bruno teaches the program management system according to claim 4, as referenced above. Kölhi fails to explicitly teach wherein the input data is entered by a user through an operation on the client after the program is received from the program storage system.
However, Faulhaber teaches:
wherein the input data is entered by a user through an operation on the client “The user may upload training data 1016 to the provider network 199 (or cause the provider network 199 to obtain the training data) at circle '1 ', which may be stored in a storage location (e.g., a storage "bucket" of storage virtualization service 1002)), and can issue a request to begin the training process (not illustrated), and thus the container 1012 is run in the model training system 120 at circle '2' based on the container image 1011” [Faulhaber ¶ 126]. “In some embodiments, users, by way of user devices 102, interact with the model training system 120 to provide data that causes the model training system 120 to train one or more machine learning models” [Faulhaber ¶ 28].
after the program is received from the program storage system. “Thus, a client application 1008, via API requests (e.g., HTTP requests carrying an "InvokeEndpoint" call) issued to inference endpoints 1010 (e.g., at circle '7B'), can issue requests to use the model to perform an inference (e.g., in substantially "real time" as an "online" system). Additionally or alternatively, one or more inferences may be performed using inference input data 1050 (e.g., one inference, multiple inferences performed as a "batch", etc.) shown at circle '7A' stored in storage virtualization service 1002, and thus the request may include an identifier of inference input data 1050. However, in some embodiments, the request itself may include the inference input data or otherwise identify the inference input data. For example, the requests are provided to a container 1022 including inference code 1024 (which may include or cooperate with a model that is generated using model artifacts 1040), which uses an input provided by the client application (e.g., data in the request, other data at a location-such as within storage virtualization service 1002-identified by the request) to execute the model (or inference code 1024), generate inferences, and send inference results back at circle '8' (e.g., via inference endpoints 1010) to the client application 1008 (or send inference results to a storage location, such as within model prediction data store 180)” [Faulhaber ¶ 150].
With regard to claim 7, Kölhi in view of Faulhaber in view of Bruno teaches the program management system according to claim 1, as referenced above. Kölhi fails to explicitly teach wherein the input data is obtained from a predetermined location.
However, Faulhaber teaches wherein the input data is obtained from a predetermined location. “Prior to beginning the training process, in some embodiments, the model training system 120 retrieves training data from the location indicated in the training request. For example, the location indicated in the training request can be a location in the training data store 160. Thus, the model training system 120 retrieves the training data from the indicated location in the training data store 160. In some embodiments, the model training system 120 does not retrieve the training data prior to beginning the training process” [Faulhaber ¶ 39].
With regard to claim 11, Kölhi in view of Faulhaber in view of Bruno teaches the program management system according to claim 1, as referenced above. Kölhi further teaches wherein the program is a machine learning model. “This disclosure proposes creating an entirely new class of highly individualized end-user-specific metadata streams by leveraging and combining information from dynamically structured chains and combinations of artificial intelligence (AI) and machine learning (ML) image classification models and/or audio classification models” [Kölhi ¶ 4].
With regard to claim 12, Kölhi teaches:
A program management method comprising: … storing the program by a program storage system; “Classification models database 524 may be located in a memory of media server 500, or may be located in one or more remote servers. Classification models database 524 transmits 526 the requested classification models to media server 500” [Kölhi ¶ 49].
receiving a transmission request for the program from a user of the user system who is different from the developer by the program storage system; “Media processing circuitry 512 identifies a type of the media content and transmits 520 a request for appropriate classification models to transceiver circuitry 506. Transceiver circuitry 506 transmits 522 the request to classification models database 524” [Kölhi ¶ 49].
transmitting the program to a user system by the program storage system in response to a reception of the transmission request, “Classification models database 524 transmits 526 the requested classification models to media server 500. Transceiver circuitry 506 receives the classification models and transmits 528 the classification models to memory 530” [Kölhi ¶ 49]. “Transceiver circuitry 506 transmits 508 the media stream to control circuitry 510, where it is received using media processing circuitry 512. Control circuitry 510 may be based on any suitable processing circuitry and comprises control circuitry and memory circuitry, which may be disposed on a single integrated circuit or may be discrete components” [Kölhi ¶ 47, fig. 5 Examiner notes, the control circuity 510 and all that it comprises is considered the user system].
receiving the program by the user system, the program being transmitted from the program storage system; Classification models database 524 transmits 526 the requested classification models to media server 500. Transceiver circuitry 506 receives the classification models and transmits 528 the classification models to memory 530” [Kölhi ¶ 49]. “Memory 530 transmits 532 the classification models to media processing circuitry 512. Media processing circuitry 512 uses the classification models to identify objects within the media stream” [Kölhi ¶ 50].
entering the input data into the program by the user system; “Transceiver circuitry 606 also transmits 614 the media stream (input data) to media processing circuitry 616” [Kölhi ¶ 53]. “Memory 530 transmits 532 the classification models to media processing circuitry 512. Media processing circuitry 512 uses the classification models to identify objects within the media stream” [Kölhi ¶ 50].
obtaining, by the user system, an output from the program when the input data is entered into the program; “Memory 530 transmits 532 the classification models to media processing circuitry 512. Media processing circuitry 512 uses the classification models to identify objects within the media stream … Metadata describing each identified object is then transmitted 534 to metadata output circuitry 536” [Kölhi ¶ 50].
Kölhi fails to teach the user system storing input data to be entered into the program; and deleting the program from the user system.
However, Faulhaber teaches:
the user system storing input data to be entered into the program; “The user may upload training data 1016 to the provider network 199 (or cause the provider network 199 to obtain the training data) at circle '1 ', which may be stored in a storage location (e.g., a storage "bucket" of storage virtualization service 1002)), and can issue a request to begin the training process (not illustrated), and thus the container 1012 is run in the model training system 120 at circle '2' based on the container image 1011” [Faulhaber ¶ 126].
and deleting the program from the user system “In some embodiments, the user, via the user device 102, can transmit a request to the model training system 120 to stop the machine learning model training process. The model training system 120 can then instruct the virtual machine instance 122 to delete the ML training container 130 and/or to delete any model data stored in the training model data store 175” [Faulhaber ¶ 48].
It would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kölhi to incorporate the teachings of Faulhaber and include: the user system storing input data to be entered into the program; and deleting the program from the user system. Doing so would allow for users to enter input to the program in real time utilizing the stored data. “Thus, a client application 1008, via API requests (e.g., HTTP requests carrying an "InvokeEndpoint" call) issued to inference endpoints 1010 (e.g., at circle '7B'), can issue requests to use the model to perform an inference (e.g., in substantially "real time" as an "online" system). Additionally or alternatively, one or more inferences may be performed using inference input data 1050 (e.g., one inference, multiple inferences performed as a "batch", etc.) shown at circle '7A' stored in storage virtualization service 1002, and thus the request may include an identifier of inference input data 1050” [Faulhaber ¶ 150].
Kölhi in view of Faulhaber fails to explicitly teach receiving a program from a developer client used by a developer of the program by a program storage system; receiving a transmission request for the program from a user of the user system who is different from the developer by the program storage system; and deleting the program from the user system upon receiving a delete instruction associated with the program from the developer client, wherein the developer client cannot access the user system.
However, Bruno teaches:
receiving a program from a developer client used by a developer of the program; “For example, some programs may be provided by third-party software developers and/or vendors, either affiliated with or not affiliated with a specific mobile operator. Such developers and/or vendors may submit applications, updates, revocations, for inclusion on the mobile device application server 116 via a developer console 138 that may be provided, for example, as a part of a software development kit provided by the operator of the mobile device application server 116, by a mobile operator, etc” [Bruno ¶ 21].
receiving a transmission request for the program from a user of the user system who is different from the developer by the program storage system by a program storage system; “Such applications may be provided by an Internet-connected service provider, such as a mobile service provider, mobile device manufacturer, mobile device software manufacturer, and/or third party, via an application server that acts as an "application store" from which users can download applications, sometimes for a fee. In some situations, it may be wished to revoke an application that is currently available to users and has previously been downloaded by one or more users” [Bruno ¶ 1-2]. “For example, such instructions may be executable to communicate with mobile devices 102, 104, 106 over the mobile network 108 and WAN 114 to provide applications, to synchronize state, revoke applications, etc.; to communicate with the database 118 to execute search queries and communicate search results to the mobile devices 102, 104 106; and to perform various other functions and operations, including but not limited to those described herein” [Bruno ¶ 17]. “End-users of the mobile devices 102, 104, 106 also may be able to load applications onto a mobile device in ways other than during a communication session with the application server 116. For example, a removable media storage device, such as a flash memory drive or the like, may be used to side load an application onto a mobile device” [Bruno ¶ 19].
and deleting the program from the user system upon receiving a delete instruction associated with the program from the developer client, “For example, some programs may be provided by third-party software developers and/or vendors, either affiliated with or not affiliated with a specific mobile operator. Such developers and/or vendors may submit applications, updates, revocations, for inclusion on the mobile device application server 116 via a developer console 138 that may be provided, for example, as a part of a software development kit provided by the operator of the mobile device application server 116, by a mobile operator, etc” [Bruno ¶ 21]. “For example, as depicted in FIG. 2, the revocation instruction may be received from a vendor or developer 204, for example, if a flaw or bug is discovered in an application” [Bruno ¶ 26]. “Continuing with method 200, after receiving the application revocation request, an application revocation instruction is sent, at 212, to one or more mobile devices on which the revoked application is stored … Further, the revocation instruction may be configured to cause the selected application to be deleted from storage on the mobile device, or may be configured to mark the selected application as blacklisted, but allow it to remain in storage” [Bruno ¶ 29].
wherein the developer client cannot access the user system. “For example, some programs may be provided by third-party software developers and/or vendors, either affiliated with or not affiliated with a specific mobile operator. Such developers and/or vendors may submit applications, updates, revocations, for inclusion on the mobile device application server 116 via a developer console 138 that may be provided, for example, as a part of a software development kit provided by the operator of the mobile device application server 116, by a mobile operator, etc” [Bruno ¶ 21].
Bruno is considered to be analogous to the claimed invention because it is in the same field of program loading. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kölhi in view of Faulhaber to incorporate the teachings of Bruno and include: receiving a program from a developer client used by a developer of the program by a program storage system; receiving a transmission request for the program from a user of the user system who is different from the developer by the program storage system; and deleting the program from the user system upon receiving a delete instruction associated with the program from the developer client, wherein the developer client cannot access the user system. Doing so would allow a developer to cause the removal of flawed programs from users. “For example, as depicted in FIG. 2, the revocation instruction may be received from a vendor or developer 204, for example, if a flaw or bug is discovered in an application” [Bruno ¶ 26].
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Kölhi (US 2024/0259640 A1) in view of Faulhaber (US 2019/0155633 A1) in view of Bruno (US 2010/0262959 A1) in view of Mochizuki (US 2022/0011987 A1).
With regard to claim 8, Kölhi in view of Faulhaber in view of Bruno teaches the program management system according to claim 1, as referenced above. Kölhi in view of Faulhaber in view of Bruno fails to teach wherein deleting the program includes deleting the program from the user system in response to when an input of the input data to the program and acquisition of an output from the program according to the input are performed once.
However, Mochizuki teaches wherein deleting the program includes deleting the program from the user system in response to when an input of the input data to the program and acquisition of an output from the program according to the input are performed once. “The program processing unit 68 may delete the correspondence processing control program from the memory 52 after the processing on the target data is completed. Specifically, after the processing on the target data is completed, the program processing unit may delete the file related to the correspondence processing control program developed on the memory 52, and may delete the correspondence processing control program itself without storing the correspondence processing control program in the program spool 58” [Mochizuki ¶ 102]. “For example, in a case where the job is a writing job of requesting writing of target data (input) to a recording medium and the correspondence processing control program is a writing control program, the execution control unit 66 executes the writing control program to execute compression processing of compressing the volume of the target data. Then, the execution control unit 66 transmits the compressed target data (output) from the communication interface 50 to the writing device, and causes the writing device to execute writing processing of writing the target data to a recording medium such as a DVD. Accordingly, the writing job is completed” [Mochizuki ¶ 96].
Mochizuki is considered to be analogous to the claimed invention because it is in the same field of unloading. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kölhi in view of Faulhaber in view of Bruno to incorporate the teachings of Mochizuki and include: wherein deleting the program includes deleting the program from the user system in response to when an input of the input data to the program and acquisition of an output from the program according to the input are performed once. Doing so would allow for the freeing of space in memory. “In a case where the correspondence processing control program is in the archive format, the program processing unit 68 deletes the file related to the correspondence processing control program developed on the memory 52, and deletes the archive file without storing the archive file in the program spool 58. Thus, it is possible to increase the free space of the memory 52” [Mochizuki ¶ 102].
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Kölhi (US 2024/0259640 A1) in view of Bruno (US 2010/0262959 A1).
With regard to claim 13, Kölhi teaches:
A non-transitory information storage medium storing a program management program that causes a computer storing input data to: “Memory 530 may be any suitable electronic storage device such as random-access memory, read-only memory, hard drives, optical drives, solid state devices, quantum storage devices, or any other suitable fixed or removable storage devices, and/or any combination of the same” [Kölhi ¶ 49]. “Control circuitry 510 may be based on any suitable processing circuitry and comprises control circuitry and memory circuitry, which may be disposed on a single integrated circuit or may be discrete components” [Kölhi ¶ 47]. “Media server 500 receives 502 media data (input data) from media source 504. Media source 504 may be a media storage device, a live media ingest server, a broadcast media receiver, a multicast media receiver, a unicast media receiver, or any other suitable device for providing media data for streaming to client devices” [Kölhi ¶ 46].
receive a program from a program storage system Classification models database 524 (program storage system) transmits 526 the requested classification models to media server 500. Transceiver circuitry 506 receives the classification models and transmits 528 the classification models to memory 530” [Kölhi ¶ 49]. “Memory 530 transmits 532 the classification models to media processing circuitry 512. Media processing circuitry 512 uses the classification models to identify objects within the media stream” [Kölhi ¶ 50].
enter the input data into the program; “Transceiver circuitry 606 also transmits 614 the media stream (input data) to media processing circuitry 616” [Kölhi ¶ 53]. “Memory 530 transmits 532 the classification models to media processing circuitry 512. Media processing circuitry 512 uses the classification models to identify objects within the media stream” [Kölhi ¶ 50].
obtain an output from the program when the input data is entered into the program; “Memory 530 transmits 532 the classification models to media processing circuitry 512. Media processing circuitry 512 uses the classification models to identify objects within the media stream … Metadata describing each identified object is then transmitted 534 to metadata output circuitry 536” [Kölhi ¶ 50].
Kölhi fails to explicitly teach a program storage system which receives the program from a developer client used by a developer of the program; and delete the program from the computer upon receiving a delete instruction associated with the program from the developer client, wherein the developer client cannot access the user system.
However, Bruno teaches:
a program storage system which receives the program from a developer client used by a developer of the program; “For example, some programs may be provided by third-party software developers and/or vendors, either affiliated with or not affiliated with a specific mobile operator. Such developers and/or vendors may submit applications, updates, revocations, for inclusion on the mobile device application server 116 via a developer console 138 that may be provided, for example, as a part of a software development kit provided by the operator of the mobile device application server 116, by a mobile operator, etc” [Bruno ¶ 21].
and delete the program from the computer upon receiving a delete instruction associated with the program from the developer client, “For example, some programs may be provided by third-party software developers and/or vendors, either affiliated with or not affiliated with a specific mobile operator. Such developers and/or vendors may submit applications, updates, revocations, for inclusion on the mobile device application server 116 via a developer console 138 that may be provided, for example, as a part of a software development kit provided by the operator of the mobile device application server 116, by a mobile operator, etc” [Bruno ¶ 21]. “For example, as depicted in FIG. 2, the revocation instruction may be received from a vendor or developer 204, for example, if a flaw or bug is discovered in an application” [Bruno ¶ 26]. “Continuing with method 200, after receiving the application revocation request, an application revocation instruction is sent, at 212, to one or more mobile devices on which the revoked application is stored … Further, the revocation instruction may be configured to cause the selected application to be deleted from storage on the mobile device, or may be configured to mark the selected application as blacklisted, but allow it to remain in storage” [Bruno ¶ 29].
wherein the developer client cannot access the user system. “For example, some programs may be provided by third-party software developers and/or vendors, either affiliated with or not affiliated with a specific mobile operator. Such developers and/or vendors may submit applications, updates, revocations, for inclusion on the mobile device application server 116 via a developer console 138 that may be provided, for example, as a part of a software development kit provided by the operator of the mobile device application server 116, by a mobile operator, etc” [Bruno ¶ 21].
Bruno is considered to be analogous to the claimed invention because it is in the same field of program loading. Therefore, it would be obvious to someone of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kölhi in view of Faulhaber to incorporate the teachings of Bruno and include: a program storage system which receives the program from a developer client used by a developer of the program; and delete the program from the computer upon receiving a delete instruction associated with the program from the developer client, wherein the developer client cannot access the user system. Doing so would allow a developer to cause the removal of flawed programs from users. “For example, as depicted in FIG. 2, the revocation instruction may be received from a vendor or developer 204, for example, if a flaw or bug is discovered in an application” [Bruno ¶ 26].
Response to Arguments
Applicant's arguments filed 07/29/2026 have been fully considered but they are not persuasive. Applicant argues in substance:
I. In attempting to disclose the former feature, the examiner pointed to paragraph [0051] of Tevathan. However, as the feature was written in the alternative "or", the examiner did not address the second part of the above feature of "upon receiving a delete instruction associated with the program from the developer client". Applicant submits that the remaining feature of "upon receiving a delete instruction associated with the program from the developer client" is not disclosed or suggested by any of the cited references.
As independent claims 12 and 13 contain similar features to independent claim 1, please see applicant's discussion of claim 1 above.
As each of dependent claims 2-7 and 11 ultimately depend from independent claim 1, please see applicant's discussion of claim 1 above.
As dependent claim 8 depends from independent claim 1, please see applicant's discussion of claim 1 above.
a) Applicant’s arguments with respect to claim(s) 1-8 and 11-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
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.
Examiner respectfully requests, in response to this Office action, support be shown for language added to any original claims on amendment and any new claims. That is, indicate support for newly added claim language by specifically pointing to page(s) and line number(s) in the specification and/or drawing figure(s). This will assist Examiner in prosecuting the application.
When responding to this Office Action, Applicant is advised to clearly point out the patentable novelty which he or she thinks the claims present, in view of the state of the art disclosed by the references cited or the objections made. He or she must also show how the amendments avoid such references or objections. See 37 CFR 1.111(c).
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ARI F RIGGINS whose telephone number is (571)272-2772. The examiner can normally be reached Monday-Friday 7:00AM-4:30PM.
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, Bradley Teets can be reached at (571) 272-3338. 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.
/A.F.R./Examiner, Art Unit 2197
/BRADLEY A TEETS/Supervisory Patent Examiner, Art Unit 2197
