DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is responsive to communication filed on 02/24/2026.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 16 – 17, 19 – 23, and 25 - 31 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by MEZAAEL et al (US 2020/0348923; hereinafter MEZAAEL).
Regarding claim 16, MEZZAEL discloses a method for transferring a file between a stationary communication participant 204, FIG. 2) and a mobile communication participant (128, fig. 2), which comprises the steps of:
splitting the file to be transferred into a plurality of data blocks (abstract; paragraphs [0026], [0028]; MEZAAEL discloses that the manager 204 may be configured to address such issue by dividing the update files into partitions and facilitate the fleet vehicles as well as other entities (e.g. the mobile device 128) to work collaboratively to perform update file transactions);
distributing the plurality of data blocks to various storage devices disposed in a decentralized manner (paragraphs [0026], [0028]; MEZAAEL discloses that multiple fleet vehicles 102 may be configured to each download different partitions for the same update file, and share the partitions once connected to each other, e.g. via the DSRC link 182. The manager 204 may be configured to collect necessary information from various nodes of the blockchain network 202 for planning/coordination related to the vehicles 102 update. ) according to at least one parameter relating to the mobile communication participant (paragraphs [0026], [0028], [0030]; MEZAAEL discloses that the cloud 172 may be configured to only send the partitions when certain predefined conditions are met. For instance, the predefined condition may include a battery level of the entity and only transmit the data partition when the battery level is above a threshold to prevent drainage of the battery. Additionally, the condition may include certain predefined network connections and only send the data when the entities are connected to the cloud via a free-of-charge network (e.g. a Wi-Fi network).); and
transferring the plurality of data blocks belonging to the file between the mobile communication participant and the various storage devices being predetermined storage devices and/or transferring the plurality of data blocks between the stationary communication participant and the predetermined storage devices for a purpose of transferring the file (paragraphs [0028], [0030]; MEZAAEL discloses that responsive to receiving the data partitions, the entities store the data in the storage (e.g. the storage 110, and/or the storage 158) and wait until later connected to the corresponding entities to start sharing. For instance, at operation 412, the mobile device 128 connects to the vehicle 102a and starts to transfer the data partition to the vehicle 102a. At operation 414, the fleet vehicles 102a and 102b connects to each other and starts to transfer data. The data transfer between the fleet vehicles 102a and 102b may be duplex. The vehicle 102a may receive data partitions from the vehicle 102b while transmitting data partitions to the vehicle 102b so the update data may be shared between the fleet vehicles 102).
Regarding claim 17, MEZZAEL discloses the method according to claim 16, which further comprises distributing the plurality of data blocks of the file to predetermined ones of the various storage devices according to an attribute of the file (paragraph [0026]; MEZAAEL discloses that depending on the specific update, some updates may require a large amount of data transmission between the cloud 172 and the vehicles 102, which may be impractical due to restraints such as network subscription access. The manager 204 may be configured to address such issue by dividing the update files into partitions and facilitate the fleet vehicles as well as other entities (e.g. the mobile device 128) to work collaboratively to perform update file transactions. For instance, the manager 204 may divide a large update file from the vehicle manufacturer 222 into multiple smaller partitions and transfer the smaller partitions to the mobile device 128 associated with the vehicle 102a via Wi-Fi overnight).
Regarding claim 19, MEZAAEL discloses the method according to claim 16, which further comprises distributing the plurality of data blocks to predetermined ones of the various storage
devices according to an event plan relating to the mobile communication participant (paragraph [0029]; MEZAAEL discloses that at operation 402, the cloud 172, which includes the manager 204, detects a vehicle software update for multiple fleet vehicles 102. The software update may be applicable for both vehicle 102a and vehicle 102b. At operation 404, the cloud 172 collects usage data from various entities of the vehicle network 202 to analyze associations therebetween. The usage data may include any past or current data/log from the entity indicative of a usage pattern and/or connection associations with other entities).
Regarding claim 20, MEZZAEL discloses the method according to claim 16, wherein, for a purpose of transferring the file from the stationary communication participant to the mobile
communication participant, at least one data block of the plurality of data blocks is
transferred to various ones of the various storage devices (paragraph [0024]; MEZAAEL discloses that the fleet manager 204 may serve as a node of the blockchain network 202 configured to coordinate and manage software update for vehicles 102. Each node of the blockchain network 202 may be configured to maintain a distributed ledger individually within its own storage device. For instance, the vehicle 102a may be configured to maintain the distributed ledger 206 stored in the storage 106. Each distributed ledger maintained by each node of the blockchain network 202 may include multiple blocks for data logging purposes ).
Regarding claim 21, MEZZAEL discloses the method according to claim 16, which further comprises transferring an item of assignment information relating to storage locations of the
data blocks for a purpose of transferring the file between the mobile communication
participant and the stationary communication participant (paragraphs [0026], [0029]; MEZAAEL discloses that The manager 204 may be configured to address such issue by dividing the update files into partitions and facilitate the fleet vehicles as well as other entities (e.g. the mobile device 128) to work collaboratively to perform update file transactions ).
Regarding claim 22, MEZZAEL discloses the method according to claim 21, wherein the data blocks of the file to be transferred which are downloaded from the various storage devices by the
mobile communication participant or the stationary communication participant are assembled on a basis of the assignment information (paragraph [0026]; MEZAAEL discloses that the manager 204 may divide a large update file from the vehicle manufacturer 222 into multiple smaller partitions and transfer the smaller partitions to the mobile device 128 associated with the vehicle 102a via Wi-Fi overnight. Along with the partitions, instructions and identifier may also be transferred to allow the mobile device 128 to send the partitions to the target vehicle 102 once connected e.g. via the wireless connection 130. Additionally, multiple fleet vehicles 102 may be configured to each download different partitions for the same update file, and share the partitions once connected to each other, e.g. via the DSRC link 182 ).
Regarding claim 23, MEZZAEL discloses the method according to claim 21, which further comprises verifying a complete transfer of all the data blocks associated with the file on a
basis of the assignment information (paragraph [0028]; MEZAAEL discloses that at operation 310, the manager 204 checks and verifies if the digital entity has already had any part of the update data. Due to the data sharing nature of the blockchain network 202, one partition of update data may be shared across the whole network 202 between multiple vehicles 102 and nodes. In some situations, the digital entity identified by the manager 204 may already had the full or a part of the update data. In this case, it may be unnecessary for the digital entity to re-download the data).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over MEZAAEL et al (US 2020/0348923; hereinafter MEZAAEL) in view of MAHOOD A et al (“Mobility-aware edge caching for connected cars”; hereinafter MAHOOD).
Regarding claim 18, MEZZAEL discloses all the limitation in claim 16, but fails to specifically disclose distributing the plurality of data blocks to predetermined ones of the various storage devices according to an item of location information relating to the mobile communication participant.
MAHMOOD, in an analogous art, discloses distributing the plurality of data blocks to predetermined ones of the various storage devices according to an item of location information relating to the mobile communication participant (page 2; MAHOOD discloses that a group of nearby ENs are controlled
by an Area Controller (AC), which resides in the network backhaul. We assume that the AC knows or can predict the ENs that a car will traverse in the next few minutes, and knows the distribution of the dwell time under each of them (e.g., based on past measurements). The AC is also aware of the available
room in the caches of ENs and of content requests made by the passing-by users. Based on such information, the AC can define which chunks of which content each EN should cache and instruct ENs accordingly.).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teaching of MEZAAEL by distributing the plurality of data blocks to predetermined ones of the various storage devices according to an item of location information relating to the mobile communication participant as evidenced by MAHMOOD for the purpose of providing the most efficient ways to decrease the access delay to the content and to decrease the congestion in the network; thereby providing a better quality of experience to users.
Claim 24 is rejected under 35 U.S.C. 103 as being unpatentable over MEZAAEL et al (US 2020/0348923; hereinafter MEZAAEL) in view of Mark TAYLOR (US 2024/0291645; hereinafter TAYLOR).
Regarding claim 24, MEZZAEL discloses all the limitations, but fails to specifically disclose confirming a receipt of all the data blocks belonging to the file by transferring a
confirmation of receipt.
TAYLOR, in an analogous art, discloses confirming a receipt of all the data blocks belonging to the file by transferring a confirmation of receipt (paragraph [0228];TAYLOR discloses that Upon receipt of all the data blocks, and the pointers key, at just before the recipient needs to know their orders, and its associated data-the local CPU reassembles data blocks 2760; then confirms receipt 2770 by way of feedback to the sender system. To confirm that orders have been received on time 2766).
Thus, it would have been obvious to one of ordinary skill in the art before the effective filing date of the invention to modify the teaching of MEZAAEL by confirming a receipt of all the data blocks belonging to the file by transferring a confirmation of receipt as evidenced by TAYLOR for the purpose of assuring that transferred data blocks have been received in a reliable manner.
Claims 25 and 30, and 31 incorporate substantively all the limitations of claim 16 in system and computer product form rather than method form. The reasons for rejecting claim 1 apply in claims 25, 30, and 31. Therefore, claims 25, 30, and 31 are rejected for the same reasons.
Regarding claim 26, MEZAAEL discloses the communication system according to claim 25, wherein said mobile communication participant is a vehicle (102a, fig. 1; abstract; paragraphs [0018], [0021].
Regarding claim 27, MEZAAEL discloses the communication system according to claim 25, wherein said storage devices are disposed along a specified route of said mobile communication participant (paragraphs [0018], [0026]).
Regarding claim 28, MEZAAEL discloses the communication system according to claim 25, wherein said storage devices are in each case part of a data processing device disposed at a location of said storage devices (paragraphs [0018],).
Regarding claim 29, the Examiner takes Official Notice” that having a vehicle which is a rail-borne vehicle is old and well known the art in the area of transferring files.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rhys Newman (US 10,158,483 Newman) discloses systems and methods for efficiently and securely storing data in a distributed data storage system.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YVES DALENCOURT whose telephone number is (571)272-3998. The examiner can normally be reached M-F 8AM-5: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, Ario Etienne can be reached at 571-272-4001. 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.
/YVES DALENCOURT/ Primary Examiner, Art Unit 2457
Prosecution Insights