DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
With respect to Applicant’s amendment of Claims 1, 3 and 19 with regards to minor informalities, the claim objection with respect to the same has been withdrawn.
Claim Interpretation
The Office notes that Claim 3 contains the wrong status identifier, “(Previously Presented)”, which should be “(Currently Amended)”, as the claim contains amendments not previously presented. For purposes of examination the Office has interpreted the status of Claim 3 as being ‘Currently Amended’. The Office respectfully requests that the Applicant confirm the intended status of Claim 3 in their next formal response.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
As originally indicated in the Non-Final Rejection mailed August 30, 2024, the claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f):
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f). The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) except as otherwise indicated in an Office action.
This application includes one or more claim limitations in Claims 1, 4, 6-9 and 20 that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitations are:
“a deployment orchestrator… the deployment orchestrator locates…” in Claim 1, as well as further “deployment orchestrator” functional language in at least Claims 4 and 6-9.
“a deployment conductor… the deployment conductor receives…,” “a package selector… determining software packages…” and “a location selector …determining the location…” in Claim 20.
Because these claim limitations are being interpreted under 35 U.S.C. 112(f) Claims 1, 4, 6-9 and 20 are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
The following paragraphs disclose the corresponding structure associated with the identified limitations:
Paragraph [0043]-[0044] discloses “a deployment orchestrator”.
Paragraph [0042] discloses “a deployment conductor”.
Paragraphs [0036]-[0037] and [0040]-[0042] disclose “a package selector”.
Paragraphs [0036]-[0037] and [0043]-[0046] disclose “a location selector”.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f).
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-2, 5-6, 8, 11-12, 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Landman (US PGPUB 2021/0218800; hereinafter “Landman”) in view of Long et al. (US PGPUB 2022/0046072; hereinafter “Long”), Medved et al. (US Patent 8,751,613; hereinafter “Medved”), Yalagandula et al. (US PGPUB 2008/0181135; hereinafter “Yala”) and Aaron et al. (US PGPUB 2009/0327918; hereinafter “Aaron”).
Claim 1: (Currently Amended)
Landman teaches a software deployment system comprising:
a deployment orchestrator coupled to a mobile network (Fig. 3A: Server 340. [0032] “The server (e.g., the tracker module) plays an active role to inform peer devices of the availability of different portions of a file from different peer devices.” [0055] “Users can interact with server 110 (and/or server 168) using a device via one or more networks, such as network 120.” [0043] “network 120 may include any type of communications network, such as a … cellular communication network.”); and
a plurality of mobile end devices communicating with each other through the mobile network (Fig. 3A: Node Devices 314, 342 and 360. [0048] “node device 160 includes… a mobile phone, a cellular phone, a satellite phone.”),
wherein at least one of the mobile end devices includes a support package repository storing software packages (Fig. 3A: Node Device 360 comprising Memory 364. [0047] “Node device 160 includes one or more files 162. To illustrate, software (e.g., packages).” [0082] “memory 364 may include one or more files (e.g., software). For example, memory 364, such as an LRU storing one or more files, may include the one or more files 369. Files 369 may enable node device 360 to engage in P2P downloading with other nodes as described herein.”),
wherein when a new mobile end device requires software package deployment, the deployment orchestrator locates the at least one of the mobile end device with the support package repository, and wherein the new mobile end device receives software packages from the mobile end device including the support package repository through the mobile network ([0086] “During operation of system 300, one or more node devices may register with server 340.” [0088] “Node device 360 may identify one or more files for downloading and may send a download request 384 to server 340… download request 384 may include a peer information request 385 for one or more peer devices that include one or portions of a file requested by node device 360.” [0093] “server 340 (e.g., peer information generator 326) may check with one or more registered peer devices to determine whether or not the peer devices has the file in storage.” [0096] “Server 340 may identify which portions of the file are stored at which peer devices based on tracking information 116. For each node device, server 340 may generate a bit field (e.g., a bitset) and send the bit field information to node device 360.” [0098] “node device 360 can send requests, via the HTTP/2 to one or more peer devices for the portion… Node device 360 may receive the requested file from node device 341.”).
With further regard to Claim 1, Landman does not teach the following, however, Long teaches:
wherein each of the mobile end devices provides location related data to the deployment orchestrator when the mobile end device changes location and wherein the deployment orchestrator stores a location of each of the mobile end devices ([0078] “FIG. 3 shows exemplary interactions among individual nodes within a hybrid network.” [0079] “Viewer 208 then transmits ID 377 along with other attributes, such as… its geolocation (e.g., latitude and longitude)… Discovery service 364 may then access a list of peers from a database 368 of smart tracker 214,” wherein the “viewer” node provides its geolocation to the “discovery service”, i.e. the “deployment orchestrator” as further taught above in Landman. [0089] “In FIG. 3, in order to provide a list of candidate peer nodes, discovery service 364 of tracker server 214 may record the location information of each peer joining the network, including its … geographical location such as latitude/longitude.”), and
the deployment orchestrator locates the at least one of the mobile end devices with the support package repository having a location in proximity to the new mobile end device by the provided location related data ([0089] “discovery service 364 may perform a spatial query to retrieve a list of candidate peers that are in close proximity and can provide data delivery quickly and efficiently.” [0093] “At step 483, a content type of the requested data file is extracted from the received request. Also extracted is… a geolocation of the viewer peer node. At step 484, a peer list is generated by selecting, from peer nodes currently active in the network, one or more cacher peer nodes to provide access to the one or more fragments of the data file, where each selected cacher peer node is selected based on the at least one of the network location of the viewer peer node and the geolocation of the viewer peer node, at least one of a network location of the selected cacher peer node and a geolocation of the selected cacher peer node, and the content type of the requested data file. At step 485, the generated peer list is transmitted to the viewer peer node,” wherein the “support package repository” is taught above in Landman.).
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 modified the system as disclosed by Landman with the location-based deployment as taught by Long in order “to reduce overall packet round-trip time, improve stream delivery quality, and reduce CDN bandwidth costs” (Long [0042]).
With further regard to Claim 1, Landman in view of Long does not teach the following, however, Medved teaches:
wherein each of the mobile end devices provides location related data to the deployment orchestrator when the mobile end device changes location and wherein the deployment orchestrator updates the location of mobile end devices that change location based on the location related data (Col. 8 Ln. 33: “Mobile device 16 sends information regarding its physical location to ALTO server 20 in a location update message. Such information may comprise longitude/latitude coordinates for mobile device 16… or other location-correlated information… Upon receiving the location update message, ALTO server 20 aggregates mobile device 16 and any other devices (not shown) that are proximate to mobile device 16 into a PID of a network map.” Col. 8 Ln. 52: “Mobile device 16 sends… ALTO server 20 another location update message to cause ALTO server 20 to aggregate mobile device 16 into a different PID of the network map for cellular network 6 based at least on the new physical location of mobile device 16 after movement 18.”).
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 modified the system as disclosed by Landman in view of Long with the updating of location information as taught by Medved in order “to optimize content delivery using load balancing techniques, caching, request routing, and/or content services” (Medved Col. 6 Ln. 29).
With further regard to Claim 1, Landman in view of Long and Medved does not teach the following, however, Yala teaches:
wherein the at least one of the mobile end devices in proximity is determined by determining a current threshold value, comparing the current threshold value with a comparison of the distance between the new mobile end device and the at least one of the mobile end devices, wherein the new mobile end device is in proximity to the at least one of the mobile end devices if the distance is less than the current threshold value ([0019] “Distances between nodes, closeness of nodes, observed nearest nodes and proximity of nodes are based on a network metric, such as latency (e.g., round-trip-time), network hops, bandwidth, loss rate, or another known network metric.” [0051] “A threshold may be used to determine whether a node is a k-closest to node. For example, if the distance to M5 is less than the threshold, then M5 is a k-closest node.” See also Claim 2 of Yala, “…wherein selecting k-closest nodes comprises: determining a top k-closest nodes or k-closest nodes that are less than a threshold distance.”).
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 modified the system as disclosed by Landman in view of Long and Medved with the proximity determination as taught by Yala for purposes of “efficiently and quickly locating desired data or services in large networks” (Yala [0003]).
With further regard to Claim 1, Landman in view of Long, Medved and Yala does not teach the following, however, Aaron teaches:
determining a current threshold value from an available bandwidth of the at least one of the mobile devices ([0216] “receivers are selected based on the distance between such receivers to data source 1110 and/or a data forwarding capability of these receivers.” [0217] “Receivers 3 and 4 are identified as being located relatively close to data source.” [0218] “a data forwarding capability of Receiver 3 is compared to a data forwarding capability of Receiver 4 so as to identify which of the two receivers would be better suited to forwarding the information… Each of Receivers 3 and 4 is queried as to… the amount of bandwidth that each receiver is currently dedicating to other communication endeavors.” [0219] “a communication bandwidth that is presently available to Receiver 3 is identified as being greater than a communication bandwidth that is currently available to Receiver 4. Therefore, it is determined that Receiver 3 is better suited for routing information.” [0220] “FIG. 11, Receiver 5 is determined to be located closer to Receiver 4 than to Receiver 3. However, in so much as Receiver 4 is currently unable to route information to Receiver 5, due to a low communication bandwidth currently being realized by Receiver 4, Receiver 3 is utilized to route information from data source 1110 to Receiver 5.” [0221] “Finally, Receiver 6 is determined to be located closer to Receiver 3 than to Receiver 5. However, in so much as Receiver 3 is already routing information to two receivers… Receiver 3 does not currently have a sufficient amount of available bandwidth to dedicate to an additional transmission. Therefore, in so much as Receiver 5 has a greater amount of available bandwidth, as compared to Receiver 3, Receiver 5 is utilized to route information to Receiver 6,” wherein the above disclosure, and Fig. 11 of Aaron, demonstrates that the acceptable distance for a receiver to be selected for data routing, i.e. threshold distance as taught above in Yala, is dynamically based on the amount of available bandwidth at each individual receiver.),
wherein the available bandwidth of the at least one of the mobile devices changes ([0243] “if a transmission bandwidth associated with the selected receiver begins to degrade to the point that the selected receiver can no longer efficiently route data to the other receiver, a different receiver is selected to route the information to the other receiver based on a data forwarding capability of such different receiver being adequate for such a routing endeavor.”).
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 modified the system as disclosed by Landman in view of Long, Medved and Yala with the further proximity determination as taught by Aaron so that “new data paths may be dynamically created over time so as to maximize the efficiency of the implemented data routes” (Aaron [0245]).
Claim 2:
Landman in view of Long, Medved, Yala and Aaron teaches the system of claim 1, and Landman further teaches:
wherein the deployment orchestrator includes a database including hardware information and location information for each of the plurality of mobile end devices (Fig. 2: Server 110 comprising Node Device Log 236. [0063] “node device log 236 may include topology information (e.g., location information) of one or more node devices, one or more node device identifiers, owner/manager information, file and/or software information (e.g., name, version number, size, etc.) installed at one or more node devices, or any combination there,” wherein the “topology information” and “device identifiers” are the “location information” and “hardware information” respectively.).
Claim 5:
Landman in view of Long, Medved, Yala and Aaron teaches the system of claim 1, and Landman further teaches:
wherein the deployment orchestrator includes a central repository including software packages required by any of the plurality of mobile end devices ([0042] “server 110 includes one or more files 114… File(s) 114 may include one or more binaries (e.g., a computer file that is not a text file). File(s) 114 may correspond to one or more package types”).
Claim 6:
Landman in view of Long, Medved, Yala and Aaron teaches the system of claim 5, and Landman further teaches:
wherein the deployment orchestrator creates a support package repository in one of the plurality of mobile end devices from the central repository ([0067] “Deployer 253 may be configured to initiate and/or perform a software release distribution. For example, deployer 253 provides a secure and structured platform to distribute release one or more binaries as a single coherent release bundle to multiple remote locations and update them as new release versions are produced.” [0068] “Compiling and maintaining the information by deployer 253 enables tracker 256 to perform tracking of software releases to various node devices. Additionally, or alternatively, a software release may be provisioned amongst one or more nodes devices (e.g., 160a, 160b, 160c, 160d).”).
Claim 8:
Landman in view of Long, Medved, Yala and Aaron teaches the system of claim 2, and Landman further teaches:
wherein the deployment orchestrator includes a deployment conductor that collects the location of the new mobile end device and the location of the at least one mobile end device with the support package repository (Fig. 2: Server 110 comprising Node Device Log 236. [0063] “node device log 236 may include topology information (e.g., location information) of one or more node devices”).
Claims 11-12 and 15:
With regard to Claims 11-12 and 15, these claims are equivalent in scope to Claims 1-2 and 5 rejected above, merely having a different independent claim type, and as such Claims 11-12 and 15 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1-2 and 5.
With further regard to Claim 11, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Landman reference also anticipates these additional elements of Claim 11, for example, wherein the method comprises:
creating at least one support package repository in an end device of a plurality of end devices ([0067] “Deployer 253 may be configured to initiate and/or perform a software release distribution. For example, deployer 253 provides a secure and structured platform to distribute release one or more binaries as a single coherent release bundle to multiple remote locations and update them as new release versions are produced.” [0068] “Compiling and maintaining the information by deployer 253 enables tracker 256 to perform tracking of software releases to various node devices. Additionally, or alternatively, a software release may be provisioned amongst one or more nodes devices (e.g., 160a, 160b, 160c, 160d).”).
Claim 20: (Currently Amended)
With regard to Claim 20, this claim is equivalent in scope to Claims 1-2, 5 and 8 rejected above, merely having a different independent claim type, and as such Claim 20 is rejected under the same grounds and for the same reasons as discussed above with regard to Claims 1-2, 5 and 8.
With further regard to Claim 20, the claim recites additional elements not specifically addressed in the rejection of Claim 1. The Landman reference also anticipates these additional elements of Claim 20, for example, wherein:
the deployment conductor receives a notification of a new mobile end device in communication with the mobile network ([0086] “During operation of system 300, one or more node devices may register with server 340. For example, node device 360 may perform one or more registration operations with server 340. The one or more registration operations may include node device 360 requesting and/or receiving a public certificate from server 340.”).
Claims 3-4 and 13-14 are rejected under 35 U.S.C. 103 as being unpatentable over Landman in view of Long, Medved, Yala and Aaron as applied to Claims 2 and 12 above, and further in view of Lin et al. (US PGPUB 2002/0078209; hereinafter “Lin”).
Claim 3: (Currently Amended)
Landman in view of Long, Medved, Yala and Aaron teaches all the limitations of claim 2 as described above. Landman in view of Long, Medved, Yala and Aaron does not teach the following, however, Lin teaches:
wherein the new mobile end device includes specific hardware requiring specific software packages, wherein the specific hardware includes at least one of the group of a camera, a microphone, and a Wi-Fi adaptor, and wherein the hardware information in the database of the new mobile end device includes the specific hardware ([0007] “a wide variety of different types of hardware devices that may require a driver. Consider, for example, just one of the different types of hardware devices identified above,” the “hardware devices identified above” including [0006] “Keyboards, pointing devices, scanners, and cameras.” [0016] “A referral cloud…may also be included in the network for facilitating peer-to-peer communications… for downloading appropriate software that meets a need of the consumer computer system.” [0055] “the referral cloud compares the certain criteria specified in the notification against the referral list (act 413). For example, if the notification specified that the desired software should be a driver compatible with a particular hardware driver, this act of comparing would involve finding one of more drivers listed in the referral list that are appropriate for the designated hardware device.”).
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 modified the system as disclosed by Landman in view of Long, Medved, Yala and Aaron with the hardware-specific software as taught by Lin for purposes of “improving convenience and automation involved with finding appropriate software that meets certain criteria” (Lin [0014]).
Claim 4:
Landman in view of Long, Medved, Yala, Aaron and Lin teaches the system of claim 3. However, Landman in view of Long, Medved, Yala and Aaron does not teach the following, but Lin teaches,
wherein the deployment orchestrator includes a package selector that determines software packages to support the specific hardware of the new mobile end device ([0055] “Referring back to FIG. 3, once the referral cloud 230 receives the notification describing a desire for software that meets certain criteria (act 401), and once the referral cloud .cent. automatically gathers a first set of one or more candidates for software that may potentially fulfill at least some of the certain criteria (act 411) in the form of referral list 231, the referral cloud compares the certain criteria specified in the notification against the referral list (act 413). For example, if the notification specified that the desired software should be a driver compatible with a particular hardware driver, this act of comparing would involve finding one of more drivers listed in the referral list that are appropriate for the designated hardware device.” [0056] “Once the referral cloud 230 performs this comparison, the referral cloud 230 returns information (act 313) identifying one or potentially several candidates provider computer system that may potentially provide a particular software item that meets the certain criteria originally provided by the consumer computer system in the notification. This returning of information is illustrated in FIG. 2 with arrow 3 representing a software referral download.”).
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 modified the system as disclosed by Landman in view of Long, Medved, Yala and Aaron with the software determining operation as taught by Lin for purposes of “improving convenience and automation involved with finding appropriate software that meets certain criteria” (Lin [0014]).
Claims 13-14:
With regard to Claims 13-14, these claims are equivalent in scope to Claims 3-4 rejected above, merely having a different independent claim type, and as such Claims 13-14 are rejected under the same grounds and for the same reasons as discussed above with regard to Claims 3-4.
Claims 7 and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Landman in view of Long, Medved, Yala and Aaron as applied to Claims 5 and 15 above, and further in view of Fang et al. (US PGPUB 2006/0212542; hereinafter “Fang”).
Claim 7:
Landman in view of Long, Medved, Yala and Aaron teaches all the limitations of claim 5 as described above. Landman in view of Long, Medved, Yala and Aaron does not teach the following, however, Fang teaches:
wherein the deployment orchestrator allows connection to the central repository for the deployment of software packages when no mobile end device with a support package repository is available to the new mobile end device ([0033] “the client may connect with one or more nodes in the peer list to download the file content that is available in the peer-to-peer network, and may connect with the file server external to the peer-to-peer network to download the portion of the file content that is unavailable for download in the peer-to-peer network. If none of the file content is available in the peer-to-peer network, the client may connect with the file server to download the file therefrom,” wherein the “file server” is the “central repository”.).
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 modified the system as disclosed by Landman in view of Long, Medved, Yala and Aaron with the downloading process when no end device is available as taught by Fang so that “the download of file 381 may be accelerated by providing multiple ‘sources’ and corresponding connections for obtaining constituent portions of file 381” (Fang [0038]).
Claim 16:
With regard to Claim 16, this claim is equivalent in scope to Claim 7 rejected above, merely having a different independent claim type, and as such Claim 16 is rejected under the same grounds and for the same reasons as discussed above with regard to Claim 7.
Claims 9-10 are rejected under 35 U.S.C. 103 as being unpatentable over Landman in view of Long, Medved, Yala, Aaron and Fang as applied to Claim 7 above, and further in view of Greene et al. (US PGPUB 2023/0164089; hereinafter “Greene”).
Claim 9:
Landman in view of Long, Medved, Yala, Aaron and Fang teaches all the limitations of claim 7 as described above. Landman further teaches:
wherein if the location of the mobile end device including the support package repository has not changed, determining whether service of the mobile end device is disrupted, wherein on determining a service disruption, the alive agent monitor alerts the deployment conductor and locates another mobile end device including the support package repository in proximity to the new mobile end device ([0090] “As mentioned earlier, a peer node might leave the network at any time. Hence, tracker server 214 also needs to be aware of which nodes are active. To achieve this, an active peer node may maintain a socket connection with tracker server 214 and send heartbeat signals consistently. If tracker server 214 does not receive a heartbeat for a certain amount of time, it may consider that peer node as having left the network, and updates the spatial database accordingly.”).
With further regard to Claim 9, Landman in view of Long, Medved, Yala, Aaron and Fang does not teach the following, however, Greene teaches:
wherein the deployment orchestrator includes an alive agent monitor that determines whether the location of the mobile end device including the support package repository has changed and can no longer make the support package repository available to the new mobile end device, wherein on determining a location change, the alive agent monitor alerts the deployment conductor and locates another mobile end device including the support package repository in proximity to the new mobile end device ([0247] “Typically, as a satellite is in range or in communication with a user terminal 502, such as satellite 504 shown in FIG. 12, the satellite will at some stage be moving towards a position of being out of range or where a hand-off needs to occur to another satellite such as satellite 502. The user experience is uninterrupted as they simply will continue to experience Internet access across the handoff,” wherein the “satellite” and “user terminal” function as the “end device including the support package repository” and the “new end device,” in view of the above teachings of Landman in view of Long, Medved, Yala and Fang. Further, [0248] “if the serving satellite 906 needs to hand-off to a new serving satellite as it is moving out of range, then a redundant storage satellite might need to be identified and the state of the streaming video needs to be transmitted to a new serving satellite such as satellite 912 that also is configured with the data or compute resources and can continue the download to the user terminal 502 or to provide continued access to the compute resources.”).
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 modified the system as disclosed by Landman in view of Long, Medved, Yala, Aaron and Fang with the location monitoring operations as taught by Greene in order “to either make routing decisions regarding which hardware the request should be serviced by or can make suggestions of several different satellites where the request could successfully be routed” (Greene [0099]).
Claim 10:
Landman in view of Long, Medved, Yala, Aaron, Fang and Greene teaches all the limitations of claim 9 as described above. Landman in view of Long, Medved, Yala, Aaron and Fang does not teach the following, however, Greene teaches:
wherein the deployment of software packages to the new mobile end device is initiated by the at least one mobile end device and continued by the another mobile end device ([0248] “if the serving satellite 906 needs to hand-off to a new serving satellite as it is moving out of range, then a redundant storage satellite might need to be identified and the state of the streaming video needs to be transmitted to a new serving satellite such as satellite 912 that also is configured with the data or compute resources and can continue the download to the user terminal 502 or to provide continued access to the compute resources.”).
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 modified the system as disclosed by Landman in view of Long, Medved, Yala, Aaron and Fang with the changing of download providers as taught by Greene “such that the user terminal (and the ultimate human user requesting the compute resources), in a transparent way, can access the storage satellite having the compute resources” (Greene [0219]).
Claims 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Landman in view of Long, Medved, Yala and Aaron as applied to Claim 11 above, and further in view of Kumar et al. (US PGPUB 2021/0360426; hereinafter “Kumar”).
Claim 18:
Landman in view of Long, Medved, Yala and Aaron teaches all the limitations of claim 11 as described above. Landman further teaches:
determining whether service of the mobile end device is disrupted; and locating another mobile end device including the support package repository on determining a service disruption of the mobile end device ([0090] “As mentioned earlier, a peer node might leave the network at any time. Hence, tracker server 214 also needs to be aware of which nodes are active. To achieve this, an active peer node may maintain a socket connection with tracker server 214 and send heartbeat signals consistently. If tracker server 214 does not receive a heartbeat for a certain amount of time, it may consider that peer node as having left the network, and updates the spatial database accordingly.”).
With further regard to Claim 18, Landman in view of Long, Medved, Yala and Aaron does not teach the following, however, Kumar teaches:
determining whether the location of the mobile end device including the support package repository has changed; and locating another mobile end device including the support package repository on determining a location change of the mobile end device ([0036] “Embodiments of the invention may be used to dynamically adjust the deployment location of software functions that perform a wide variety of activity, including but not limited to video streaming caching, peer-to-peer latency communications (car-to-car, for instance)…To illustrate a few specific examples, in the performance of step 220 of an embodiment, the deployment location of the software function is dynamically moved to an updated deployment location”.).
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 modified the method as disclosed by Landman in view of Long, Medved, Yala and Aaron with the changing of download providers as taught by Kumar in order “to create a low latency packet stream” (Kumar [0036]).
Claim 19: (Currently Amended)
Landman in view of Long, Medved, Yala and Kumar teaches all the limitations of claim 18 as described above. Landman in view of Long, Medved, Yala and Aaron does not teach the following, however, Kumar teaches:
wherein the deployment of software packages to the new mobile end device is initiated by the at least one end device and continued by the another mobile end device ([0036] “Embodiments of the invention may be used to dynamically adjust the deployment location of software functions that perform a wide variety of activity, including but not limited to video streaming caching, peer-to-peer latency communications (car-to-car, for instance)…To illustrate a few specific examples, in the performance of step 220 of an embodiment, the deployment location of the software function is dynamically moved to an updated deployment location”.).
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 modified the method as disclosed by Landman in view of Long, Medved, Yala and Aaron with the changing of download providers as taught by Kumar in order “to create a low latency packet stream” (Kumar [0036]).
Response to Arguments
Applicant's arguments, see Pages 7-9 of the Remarks filed July 3, 2025, with respect to the rejections under 35 U.S.C. 103 of Claims 1-16 and 18-20 have been fully considered but they are not persuasive.
With respect to the Applicant’s argument, Page 8 of the Remarks, that the newly amended language of Claims 1, 11 and 20 is not taught by the previously cited prior art, this argument has been fully considered but is moot in view of the Aaron et al. (US PGPUB 2009/0327918) reference as newly cited above in the respective rejections. The Aaron reference was previously cited in the ‘Conclusion’ section of the Non-Final Rejection dated April 10, 2025, but was not cited in the rejections of Claims 1-16 and 18-20. As such, the Office respectfully directs the Applicant’s attention to the newly modified rejections of Claims 1, 11 and 20 above for further explanation regarding how the Landman reference has been interpreted as teaching the newly amended language of Claims 1, 11 and 20.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Lochan et al. (US PGPUB 2016/0378455) discloses methods and systems for installing applications on electronic devices by transferring installation files through a local connection between electronic devices, including consideration regarding the available network bandwidth and proximity between electronic devices.
Shaikh et al. (“Routing in Multi-Hop Cellular Device-to-Device (D2D) Networks: A Survey,” 2018) discusses a comprehensive survey of routing in multi-hop D2D networks, including discussion regarding the selection of nodes in the network based on available bandwidth and proximity.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Joanne G. Macasiano whose telephone number is (571)270-7749. The examiner can normally be reached Monday to Thursday, 10:30 AM to 6:00 PM Eastern Standard Time.
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.
/J.G.M/ Examiner, Art Unit 2197
/BRADLEY A TEETS/ Supervisory Patent Examiner, Art Unit 2197