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 in response to the amendments, arguments and remarks, filed on 10/15/2025, in which claim(s) 1 and 4-19 is/are presented for further examination.
Claim(s) 1, 12 and 18 has/have been amended.
Claim(s) 2 and 3 has/have been previously cancelled.
Claim(s) 7 (and similarly claim(s) 16 and 19) is/are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Response to Amendment
Applicant’s amendment(s) to claim(s) 18 has/have been accepted. The objection(s) to the claim(s) for informalities has/have been withdrawn.
Applicant’s amendment(s) to claim(s) 1, 12 and 18 has/have been accepted.
The examiner thanks applicant’s representative for pointing out where s/he believes there is support for the amendment(s).
Response to Arguments
Applicant’s arguments with respect to claim(s) 1 and 4-19, filed on 10/15/2025, have been fully considered but they are not persuasive. Accordingly, this action has been made FINAL.
Applicant’s arguments with respect to the rejection(s) of claim(s) 1 and 4-19, under 35 U.S.C. 103, see the bottom of page 8 to page 12 of applicant’s remarks, filed on 10/15/2025, 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.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 4, 8 and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Burns, et al., US 2013/0030807 A1 (hereinafter “Burns”) in view of Reim et al., US 2018/0341989 A1 (hereinafter “Reim”) in further view of Prahlad et al., US 2022/0318206 A1 (hereinafter “Prahlad”).
Claims 1 and 11
Burns discloses a computer-implemented method for providing data to a client, comprising:
monitoring, at the client, read access operations on a file by the client, while the file is being provided as a network data stream by a network node to the client over a network connection in order to establish which file or areas of the file the client accesses, the client being configured such that it is able to receive files only via a searchable file-based data stream (Burns, [0067], see data stream and data query is received by the server and decrypted and decompressed. The server 18 sends the data to the programming interface 26, such that search engine 28 can for compare and match the transmitted data stream to the provided selected searchable data [i.e., creating the “searchable file-based data stream”]; Burns, [0065], see the user interface 42, particularly the GUI prompts the user to provide input, such as a patient's name, or a prescription [i.e., using broadest reasonable interpretation/BRI, “read access operations on a file by the client”]. The user indents the buttons or soft keys on the input/output device 40, activating the recording apparatus. The user orally speaks the requested information into the user interface 42. The recording apparatus records the data to a data stream. Notably, the recorded audible stream need not be a physical file, but can be a buffered stream. It is contemplated that the recorded audible stream can be any type of stream interfaceable with the input/output device 40; Burns, [0024], see it is contemplated that the client and server can communicate over, a Local Area Network Systems (LANS), World Area Network system (WANS), satellite systems or any other network systems [i.e., “network data stream”] known to those skilled in the art; Burns, [0066], see the recorded data stream, and data query, are encrypted and compressed according to known encryption and compression algorithms and transmitted to the connected server 18. During the execute method, the user interface 42 sends a data query requiring that the server 18 compare the recognized data generated by the search engine 28 to information contained in the database 34; Burns, [0068], see the SAPI engine 28 returns the appropriate recognized matching information that matches the transmitted data to the server 18. For example, if the user's spoken words were “John Doe,” the recognition engine 28 would return matching data in the database that the recognition engine believes matches the spoken words, such as for example, “John Doe” “Jonathan Doe” or “Jane Doe.”; Burns, [0069], see the server 18 verifies the matching recognized data by comparing the data to the information stored in the selected database 34. The database 34 uses a comparison engine to compare the matching recognized data to data contained in the database. The server retrieves the results based on the comparison to the database. The server then transmits the recognized matching data and the data query results. In this example, the database only contains a patient named “John Doe” and therefore only returns the result “John Doe.”; and Burns, [0070], see the verified matching data, in this case “John Doe,” is then encrypted and compressed for wireless transmission back to the client 12 [i.e., where the encrypted and compressed verified matching data is decrypted and decompressed at the client making them searchable]);
transmitting the network data stream containing the file to the client, the network data stream not being initially searchable for the client (See Burns, [0024] above where client and server can communicate over, a Local Area Network Systems (LANS), World Area Network system (WANS); Burns, [0069] above where the server retrieves the results based on the comparison to the database. The server then transmits the recognized matching data and the data query results [i.e., the client]; and Burns, [0070] above where the verified matching data, in this case “John Doe,” is then encrypted and compressed for wireless transmission back to the client 12 [i.e., where the encrypted and compressed verified matching data is decrypted and decompressed at the client making the them searchable, which means the data was not searchable before]);
during reception of the network data stream at the client, translating the network data stream into the searchable file-based data stream on the basis of the read access operations monitored on the client, the translating by the client occurring on the basis of the read access operations monitored (Burns, [0038], see the server 18 is connected to the client 12 using wireless communication protocols known to those skilled in the art. The server 18 includes a messaging or communicating mechanism, an encrypting/de-encrypting mechanism, a compression/decompression mechanism, an interface for the communicating with the programming interface and a database interface; Burns, [0024], see it is contemplated that the client and server can communicate over, a Local Area Network Systems (LANS), World Area Network system (WANS), satellite systems or any other network systems [i.e., “network data stream”] known to those skilled in the art; Burns, [0040], see the encrypting/deencrypting mechanism [i.e., using BRI, the encrypting/deencrypting is interpreted as “translating”] provides a secure, private data transmission with the input/output device 40 [i.e., makes the data stream searchable]. The encrypting/deencrypting uses algorithms or methods, which correspond algorithms and methods used by the client 12, such that the server 18 and client 12 can communicate; Burns, [0043], see the selected searchable data 30 is provided to the programming interface 26, such that the recognition engine 28 can generate a stream of matching recognized data 30. The matching recognized data is generated by searching the selected searchable data for matching data elements contained in the transmitted stream and creating a matching data stream containing those matching [i.e., using BRI, where the matching is interpreted as “read access operations monitored on the client”] data elements [i.e., creating a “searchable file-based data stream on the basis of the read access operations monitored on the client … occurring on the basis of the read access operations monitored”]; and Burns, [0046], see the data search engine 28 searches the data contained in the selected searchable data 30 for matching information contained in the transmitted data stream, to create a data element of recognized matching data [i.e., creating a “searchable file-based data stream on the basis of the read access operations monitored on the client … occurring on the basis of the read access operations monitored”]) and
Burns does not appear to explicitly disclose the network data stream configured to be a continuous data stream that continuously transfers the file from an initial reading position within the file that has been indicated by the read access operations monitored;
being effected by comparing a current data position of the network data stream with a current reading position within the network data stream that is indicated by a current read access operation; and
if the current reading position is different than the current data position, replacing the current read access operation with a modified read access operation on the basis of an initial read access operation by the client and the current reading position.
Reim discloses the network data stream configured to be a continuous data stream that continuously transfers the file from an initial reading position within the file that has been indicated by the read access operations monitored (Reim, [0037], see “… The data ingestion module 164 can receive the streamed files [i.e., where the initial reading position is the beginning of the first file and where continuous streaming occurs when the files are very large/long and the ingestion process is still ongoing] from the different topics from the streaming platform 160. The data ingestion module 164 can read the datasets in the log lines of the files from each respective topic, map the datasets from the log lines into fields of a common (normalized) format, transform the datasets [i.e., where the “read access operations” are being interpreted as the reading and mapping instructions that “transform the datasets”], and load the datasets for storage in the data store database 140. …” see the data is mapped into fields of a common (normalized) format, the datasets transformed, and loaded in the data store database 140, and through the mapped fields the data is searchable; and Reim, [0039], see the files are downloaded from the respective locations and streamed to a streaming platform 160 (i.e., Apache Kafka) [i.e., where Apache Kafka continuous streaming refers to the capability of Apache Kafka to hand and process a continuous flow of real-time data, see Apache Kafka overview attached]. The streaming platform 160 can convert the files into a Java stream).
Burns and Reim are analogous art because they are from the same field of endeavor such as processing data.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, having the teachings of Burns and Reim before him/her, to modify the read access of Burns to include the file transfer of Reims because of the ability to transfer different kinds of data.
The suggestion/motivation for doing so would have been to improve over conventional practices in reconciling reports from various sources, see Reim, [0010].
Therefore, it would have been obvious to combine Reim with Burns to obtain the invention as specified in the instant claim(s).
The combination of Burns and Reim does not appear to explicitly disclose being effected by comparing a current data position of the network data stream with a current reading position within the network data stream that is indicated by a current read access operation; and
if the current reading position is different than the current data position, replacing the current read access operation with a modified read access operation on the basis of an initial read access operation by the client and the current reading position.
Prahlad discloses being effected by comparing a current data position of the network data stream with a current reading position within the network data stream that is indicated by a current read access operation (See below); and
if the current reading position is different than the current data position, replacing the current read access operation with a modified read access operation on the basis of an initial read access operation by the client and the current reading position (Prahlad, [0150], see the data structure 520 consists of one or more stream headers 522 and stream data 524 [i.e., representing how to read the “network data stream”]. The stream header 522 describes a data object contained in an “N” file 506 or an “S” file 508 (e.g., its location, its size, an offset within the file, etc.). The stream data 524 contains the pointer to the data object contained in the “N” file 506 or the “S” file 508 [i.e., “current reading position is different than the current data position” and where the pointer “replacing the current read access operation with a modified read access operation” and where the insertion of the pointer is being interpreted as the “replacing the current read access operation”, where the previous read point is replaced with the new pointer in the read access operation]. For example, the pointer may give its location within the “N” file 506 or the “S” file 508. The location of the data object may be given by offsets within the “N” file 506 or the “S” file 508. For example, its location may be given by a starting offset, and its length or size. As another example, its location may be given by a starting offset and an ending offset [i.e., where the starting offset discloses “current reading position is different than the current data position”]. As previously mentioned, the data object may be in an “S” file 508 in another chunk folder, and the stream data 524 would point to this “S” file in the other chunk folder (e.g., give its location in the “S” file in the other chunk folder)”; Prahald, [0154] discloses deduplication, which takes data that has duplicate copies, picks one copy and deletes the duplicates. All of the references to the deleted duplicate copies are pointed to the kept copy. If reading the deleted copy that is the “current reading position”. Because the deleted copy no longer exists, the location of the kept copy is put in its place in order to retrieve the data. The location of the kept copy is the “current data position”; Prahlad, [0189], see a first storage operation on a first client 130 could result in the creation of the first chunk folder 804, and a second storage operation on a second client 130 could result in the creation of the second chunk folder 805. The container files 810, 811 in the first chunk folder 804 would contain the blocks of deduplicated data of the first client 130. If the two clients 130 have substantially similar data, the second storage operation on the data of the second client 130 would result in the media file system agent 240 storing primarily links to the data blocks of the first client 130 that are already stored in the container files 810, 811 [i.e., see that reading data positions in the second client, where data no longer exists, are replaced with links to the data stored in the first client, resulting in “if the current reading position is different than the current data position, replacing the current read access operation with a modified read access operation on the basis of an initial read access operation by the client and the current reading position”]. Accordingly, while a first storage operation may result in storing nearly all of the data subject to the storage operation, subsequent storage operations involving storage of similar data on the same cloud storage site 115 (or another appropriate cloud storage site) may result in substantial data storage space savings, because links to already stored data blocks can be stored instead of additional instances of data blocks).
Burns, Reim and Prahlad are analogous art because they are from the same field of endeavor such as processing data.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, having the teachings of Burns, Reim and Prahlad before him/her, to modify the file transfer read access of the combination of Burns and Reim to include the stream headers of Prahlad because of the ability to locate information in the data stream block data.
The suggestion/motivation for doing so would have been to permit the end user to perform value-added storage operations such as ILM, deduplication, content indexing, data classification, data mining or searching, E-discovery management, collaborative searching, encryption or compression, see Prahlad, [0015].
Therefore, it would have been obvious to combine Prahlad with the combination of Burns and Reim to obtain the invention as specified in the instant claim(s).
Claim(s) 11 recite(s) similar limitations to claim 1 and is/are rejected under the same rationale.
With respect to claim 11, Burns discloses a non-transitory computer-readable storage medium, configured to store instructions that, when executed by a computing apparatus having a processor, cause the processor to carry out the method as claimed in claim 1 (Burns, [0022], where a computer has memory and a processor).
Claims 4 and 14
With respect to claims 4 and 14, the combination of Burns, Reim and Prahlad discloses wherein only the initial read access operation identifies the file (Reim, [0009], see “Embodiments of the disclosed systems and methods ingest digital campaign delivery, performance and quality data feeds from each of a number of third party systems (i.e., vendors). The ingested data is then joined together using a common event-level identifier (i.e., unique transaction ID), and is further combined with contract information (i.e., information associated with the user) specific to each client (i.e., user). …”).
Claim 8
With respect to claim 8, the combination of Burns, Reim and Prahlad discloses wherein the buffer-storage steps involve:
producing a buffer-store file having a logical file size corresponding to the physical size of the file (Reim, [0039], see “… The streaming platform 160 can convert the files into a Java stream. The Java stream can be loaded into a streaming application on used by the data ingestion module 164, such as Conflux spark. Files including event level datasets can be streamed from trackers 204 to the streaming platform 160.”, where the stream data is stored is interpreted to be the “buffer”; and Prahlad, [0118], see size of buffer is configurable); and
storing the buffer-stored volume of data in the buffer-store file, sections of the file that are not included in the buffer-stored file being stored only logically, with the result that a physical file size of the buffer-store file corresponds to the size of the buffer-stored volume of data (Reim, [0039], see “… The streaming platform 160 can convert the files into a Java stream. The Java stream can be loaded into a streaming application on used by the data ingestion module 164, such as Conflux spark. Files including event level datasets can be streamed from trackers 204 to the streaming platform 160.”, where the stream data is stored is interpreted to be the “buffer”).
Claim(s) 5, 6, 9 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Burns, et al., US 2013/0030807 A1 (hereinafter “Burns”) in view of Reim et al., US 2018/0341989 A1 (hereinafter “Reim”) in further view of Prahlad et al., US 2022/0318206 A1 (hereinafter “Prahlad”) in further view of Dalal et al., US 2015/0062353 A1 (hereinafter “Dalal”).
Claim 5
Claim 5 incorporates all of the limitations above.
With respect to claim 5, the combination of Burns, Reim and Prahlad discloses wherein:
the read access operations request a read volume of data for the file or the read volume of data is defined per read access operation (Reim, [0037], see “… The data ingestion module 164 can receive the streamed files from the different topics from the streaming platform 160. The data ingestion module 164 can read the datasets in the log lines of the files from each respective topic, map the datasets from the log lines into fields of a common (normalized) format, transform the datasets, and load the datasets for storage in the data store database 140. …”); and
buffer-storing the volume of data transferred until the read volume of data has been transferred (Prahlad, [0118] recites a buffer, which discloses “buffer-storing” and the ability to modify the size of the buffer, where a buffer is an intermediate repository in which data is temporarily held, which means once the data is transferred it is no longer held because the data is no longer needed after being transferred).
The combination of Reim and Prahlad does not appear to explicitly disclose the computer-implemented method further comprises:
comparing a volume of data transferred by the network data stream with the read volume of data in order to determine a missing volume of data;
if the missing volume of data has been determined.
Dalal discloses the computer implemented method further comprises:
comparing a volume of data transferred by the network data stream with the read volume of data in order to determine a missing volume of data (Dalal, [0097] and [0098] recite creating sync locations in two streams allowing them to sync, which requires comparing the two streams and determining if the sync locations match up. The sync locations can be used to mark where data is missing in a stream and know where that data can be retrieved in the other stream);
if the missing volume of data has been determined (Dalal, [0097] and [0098] recite creating sync locations in two streams allowing them to sync, which requires comparing the two streams and determining if the sync locations match up. The sync locations can be used to mark where data is missing in a stream and know where that data can be retrieved in the other stream).
Burns, Reim, Prahlad and Dalal are analogous art because they are from the same field of endeavor such as streaming data.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, having the teachings of Burns, Reim, Prahlad and Dalal before him/her, to modify the data stream with stream headers of the combination of Burns, Reim and Prahlad to include the volume comparison of Dalal because it ensure the data has been properly transmitted.
The suggestion/motivation for doing so would have been to detect or isolate problems at the playback stage, see Dalal, [0004].
Therefore, it would have been obvious to combine Dalal with the combination of Burns, Reim and Prahlad to obtain the invention as specified in the instant claim(s).
Claim 6
With respect to claim 6, the combination of Burns, Reim, Prahlad and Dalal discloses wherein the computer-implemented method further comprises:
transmitting a modified read access operation in order to requisition the missing volume of data (Reim, [0039] recites the transfer of files which requires read access operations to request and send the files, where the files are located on storage requiring specification on which storage volume to retrieve and send the file; and Dalal, [0097] and [0098] recite creating sync locations in two streams allowing them to sync, which requires comparing the two streams and determining if the sync locations match up. The sync locations can be used to mark where data is missing in a stream and know where that data can be retrieved in the other stream).
Claim 9
Claim 9 incorporates all of the limitations above.
The combination of Burns, Reim and Prahlad does not appear to explicitly discloses wherein the buffer-storage steps further involve:
updating the buffer-stored volume of data stored in the buffer-store file, the updating involving erasing volumes of data that are no longer required from the buffer-stored file.
Dalal discloses wherein the buffer-storage steps further involve:
updating the buffer-stored volume of data stored in the buffer-store file, the updating involving erasing volumes of data that are no longer required from the buffer-stored file (Dalal, [0077]-[0085], see updating the stream and its contents; and Dalal, [0098], see replacing at the sync location).
See claim 5 above for the motivation to combine.
Claim 10
Claim 10 incorporates all of the limitations above.
The combination of Burns, Reim and Prahlad does not appear to explicitly disclose wherein sections that are stored only logically are regarded as being stored physically with a standard value.
Dalal discloses wherein sections that are stored only logically are regarded as being stored physically with a standard value (Dalal, [0077]-[0085], see updating the stream and its contents).
See claim 5 above for the motivation to combine.
5. Claim(s) 12-15, 17 and 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over Burns, et al., US 2013/0030807 A1 (hereinafter “Burns”) in view of Reim et al., US 2018/0341989 A1 (hereinafter “Reim”) in further view of Prahlad et al., US 2022/0318206 A1 (hereinafter “Prahlad”) in further view of Barton, US 2002/0034374 A1 (hereinafter “Barton”).
Claim 12
Burns discloses a computer-implemented method for providing data to a client, comprising:
monitoring, at the client, read access operations by the client on a file, while the file is being provided as a network data stream by a network node to the client over a network connection in order to establish which file or areas of the file the client accesses and the client being configured to receive files via a searchable file-based data stream (Burns, [0067], see data stream and data query is received by the server and decrypted and decompressed. The server 18 sends the data to the programming interface 26, such that search engine 28 can for compare and match the transmitted data stream to the provided selected searchable data [i.e., creating the “searchable file-based data stream”]; Burns, [0065], see the user interface 42, particularly the GUI prompts the user to provide input, such as a patient's name, or a prescription [i.e., using broadest reasonable interpretation/BRI, “read access operations on a file by the client”]. The user indents the buttons or soft keys on the input/output device 40, activating the recording apparatus. The user orally speaks the requested information into the user interface 42. The recording apparatus records the data to a data stream. Notably, the recorded audible stream need not be a physical file, but can be a buffered stream. It is contemplated that the recorded audible stream can be any type of stream interfaceable with the input/output device 40; Burns, [0024], see it is contemplated that the client and server can communicate over, a Local Area Network Systems (LANS), World Area Network system (WANS), satellite systems or any other network systems [i.e., “network data stream”] known to those skilled in the art; Burns, [0066], see the recorded data stream, and data query, are encrypted and compressed according to known encryption and compression algorithms and transmitted to the connected server 18. During the execute method, the user interface 42 sends a data query requiring that the server 18 compare the recognized data generated by the search engine 28 to information contained in the database 34; Burns, [0068], see the SAPI engine 28 returns the appropriate recognized matching information that matches the transmitted data to the server 18. For example, if the user's spoken words were “John Doe,” the recognition engine 28 would return matching data in the database that the recognition engine believes matches the spoken words, such as for example, “John Doe” “Jonathan Doe” or “Jane Doe.”; Burns, [0069], see the server 18 verifies the matching recognized data by comparing the data to the information stored in the selected database 34. The database 34 uses a comparison engine to compare the matching recognized data to data contained in the database. The server retrieves the results based on the comparison to the database. The server then transmits the recognized matching data and the data query results. In this example, the database only contains a patient named “John Doe” and therefore only returns the result “John Doe.”; and Burns, [0070], see the verified matching data, in this case “John Doe,” is then encrypted and compressed for wireless transmission back to the client 12 [i.e., where the encrypted and compressed verified matching data is decrypted and decompressed at the client making the them searchable]),
transmitting the network data stream containing the file to the client, the network data stream not being initially searchable for the client (See Burns, [0024] above where client and server can communicate over, a Local Area Network Systems (LANS), World Area Network system (WANS); Burns, [0069] above where the server retrieves the results based on the comparison to the database. The server then transmits the recognized matching data and the data query results [i.e., the client]; and Burns, [0070] above where the verified matching data, in this case “John Doe,” is then encrypted and compressed for wireless transmission back to the client 12 [i.e., where the encrypted and compressed verified matching data is decrypted and decompressed at the client making the them searchable, which means the data was not searchable before]);
during reception of the network data stream at the client, translating the network data stream into the searchable file-based data stream on the basis of the read access operations monitored on the client (Burns, [0038], see the server 18 is connected to the client 12 using wireless communication protocols known to those skilled in the art. The server 18 includes a messaging or communicating mechanism, an encrypting/de-encrypting mechanism, a compression/decompression mechanism, an interface for the communicating with the programming interface and a database interface; Burns, [0024], see it is contemplated that the client and server can communicate over, a Local Area Network Systems (LANS), World Area Network system (WANS), satellite systems or any other network systems [i.e., “network data stream”] known to those skilled in the art; Burns, [0040], see the encrypting/deencrypting mechanism [i.e., using BRI, the encrypting/deencrypting is interpreted as “translating”] provides a secure, private data transmission with the input/output device 40 [i.e., makes the data stream searchable]. The encrypting/deencrypting uses algorithms or methods, which correspond algorithms and methods used by the client 12, such that the server 18 and client 12 can communicate; Burns, [0043], see the selected searchable data 30 is provided to the programming interface 26, such that the recognition engine 28 can generate a stream of matching recognized data 30. The matching recognized data is generated by searching the selected searchable data for matching data elements contained in the transmitted stream and creating a matching data stream containing those matching [i.e., using BRI, where the matching is interpreted as “read access operations monitored on the client”] data elements [i.e., creating a “searchable file-based data stream on the basis of the read access operations monitored on the client … occurring on the basis of the read access operations monitored”]; and Burns, [0046], see the data search engine 28 searches the data contained in the selected searchable data 30 for matching information contained in the transmitted data stream, to create a data element of recognized matching data [i.e., creating a “searchable file-based data stream on the basis of the read access operations monitored on the client … occurring on the basis of the read access operations monitored”]),
Burns does not appear to explicitly disclose the network data stream being a continuous data stream that transfers the file continuously from an initial reading position within the file that has been indicated by the read access operation and the monitoring comprises storing the initial read access operation, and while the network data stream is searchable, the reading position is able to be moved freely forward or backward in the file after the initial read access operation;
the translating by the client occurring on the basis of comparing a current data position of the continuous data stream with a current reading position within the continuous data stream that is indicated by a current read access operation; and
if the current reading position is different than the current data position, replacing the current read access operation with a modified read access operation on the basis of an initial read access operation by the client and the current reading position.
Reim discloses the network data stream being a continuous data stream that transfers the file continuously from an initial reading position within the file that has been indicated by the read access operation and the monitoring comprises storing the initial read access operation, and while the network data stream is searchable (Reim, [0037], see “… The data ingestion module 164 can receive the streamed files [i.e., where the initial reading position is the beginning of the first file and where continuous streaming occurs when the files are very large/long and the ingestion process is still ongoing] from the different topics from the streaming platform 160. The data ingestion module 164 can read the datasets in the log lines of the files from each respective topic, map the datasets from the log lines into fields of a common (normalized) format, transform the datasets [i.e., where the “read access operations” are being interpreted as the reading and mapping instructions that “transform the datasets”], and load the datasets for storage in the data store database 140. …” see the data is mapped into fields of a common (normalized) format, the datasets transformed, and loaded in the data store database 140, and through the mapped fields the data is searchable; and Reim, [0039], see the files are downloaded from the respective locations and streamed to a streaming platform 160 (i.e., Apache Kafka) [i.e., where Apache Kafka continuous streaming refers to the capability of Apache Kafka to hand and process a continuous flow of real-time data, see Apache Kafka overview attached]. The streaming platform 160 can convert the files into a Java stream).
See claims 1 and 11 above for the motivation to combine.
The combination of Burns and Reim does not appear to explicitly disclose the reading position is able to be moved freely forward or backward in the file after the initial read access operation;
the translating by the client occurring on the basis of comparing a current data position of the continuous data stream with a current reading position within the continuous data stream that is indicated by a current read access operation; and
if the current reading position is different than the current data position, replacing the current read access operation with a modified read access operation on the basis of an initial read access operation by the client and the current reading position.
Prahlad discloses the translating by the client occurring on the basis of comparing a current data position of the continuous data stream with a current reading position within the continuous data stream that is indicated by a current read access operation (See below); and
if the current reading position is different than the current data position, replacing the current read access operation with a modified read access operation on the basis of an initial read access operation by the client and the current reading position (Prahlad, [0150], see the data structure 520 consists of one or more stream headers 522 and stream data 524 [i.e., representing how to read the “network data stream”]. The stream header 522 describes a data object contained in an “N” file 506 or an “S” file 508 (e.g., its location, its size, an offset within the file, etc.). The stream data 524 contains the pointer to the data object contained in the “N” file 506 or the “S” file 508 [i.e., “current reading position is different than the current data position” and where the pointer “replacing the current read access operation with a modified read access operation” and where the insertion of the pointer is being interpreted as the “replacing the current read access operation”, where the previous read point is replaced with the new pointer in the read access operation]. For example, the pointer may give its location within the “N” file 506 or the “S” file 508. The location of the data object may be given by offsets within the “N” file 506 or the “S” file 508. For example, its location may be given by a starting offset, and its length or size. As another example, its location may be given by a starting offset and an ending offset [i.e., where the starting offset discloses “current reading position is different than the current data position”]. As previously mentioned, the data object may be in an “S” file 508 in another chunk folder, and the stream data 524 would point to this “S” file in the other chunk folder (e.g., give its location in the “S” file in the other chunk folder) …).
See claims 1 and 11 above for the motivation to combine.
The combination of Burns, Reim and Prahlad does not appear to explicitly disclose the reading position is able to be moved freely forward or backward in the file after the initial read access operation.
Barton discloses the reading position is able to be moved freely forward or backward in the file after the initial read access operation (Barton, [0031], see the Linear Cache (204) is a general device for buffering the information contained in a stream of digital information, such that the data in the cache can be viewed as a snapshot of the continuous stream of digital data; Barton, [0059], see the forward function is implemented by moving the current block indicator forward through the cache by one block for each event generated by the Stream Clock; and Barton, [0063], see the reverse function is implemented by moving the current block indicator backwards through the cache by one block for each clock event generated by the SC.)
Burns, Reim, Prahlad and Barton are analogous art because they are from the same field of endeavor such as processing data.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the invention, having the teachings of Burns, Reim, Prahlad and Barton before him/her, to modify the file transfer read access with stream headers of the combination of Burns, Reim and Prahlad to include the data movement of Barton because of the ability to easily locate information in the data stream block data.
The suggestion/motivation for doing so would have been to provide easy playback functionality, see Barton, [0020].
Therefore, it would have been obvious to combine Barton with the combination of Burns, Reim and Prahlad to obtain the invention as specified in the instant claim(s).
Claim 13
With respect to claim 13, the combination of Burns, Reim, Prahlad and Barton discloses wherein the read access operation is any access to the file and the read access operation identifies at least one from the file itself and an area of the file that the client accesses (Prahlad, [0150], see the data structure 520 consists of one or more stream headers 522 and stream data 524 [i.e., representing how to read the “network data stream”]. The stream header 522 describes a data object [i.e., “at least one from the file and an area of the file”] contained in an “N” file 506 or an “S” file 508 (e.g., its location, its size, an offset within the file, etc. [i.e., “initial reading position within the file”]). The stream data 524 contains the pointer to the data object contained in the “N” file 506 or the “S” file 508. For example, the pointer may give its location within the “N” file 506 or the “S” file 508. The location of the data object may be given by offsets within the “N” file 506 or the “S” file 508. For example, its location may be given by a starting offset, and its length or size. As another example, its location may be given by a starting offset and an ending offset. As previously mentioned, the data object may be in an “S” file 508 in another chunk folder, and the stream data 524 would point to this “S” file in the other chunk folder (e.g., give its location in the “S” file in the other chunk folder) …).
Claim 15
With respect to claim 15, the combination of Burns, Reim, Prahlad and Barton discloses wherein the reading position cannot be moved freely forward or backward in the file after the initial read access operation (Prahlad, [0155], see the storage of data objects in containers such as the “N” file 506 and the “S” file 508 may create additional complexities when it comes time to prune or delete data objects involved in previous storage operations. This is because the data objects are not stored as files on the file system and thus cannot be directly referenced by the file system [i.e., “cannot be moved freely forward or backward in the file”]).
Claim 17
With respect to claim 17, the combination of Burns, Reim, Prahlad and Barton discloses wherein the buffer-storage steps involve:
producing a buffer-store file having a logical file size corresponding to the physical size of the file (Reim, [0039], see “… The streaming platform 160 can convert the files into a Java stream. The Java stream can be loaded into a streaming application on used by the data ingestion module 164, such as Conflux spark. Files including event level datasets can be streamed from trackers 204 to the streaming platform 160.”, where the stream data is stored is interpreted to be the “buffer”; and Prahlad, [0118], see size of buffer is configurable).
Claim 18
Burns discloses a computer-implemented method for providing data to a client, comprising:
monitoring, at the client, a read access operation on a file by the client, the file being provided as a network data stream by a network node to the client over a network connection, and the client being configured to receive files via a searchable file-based data stream, the read access operation being any access to the file and the read access operation configured to identify at least one client access from the file itself and an area of the file that the client accesses (Burns, [0067], see data stream and data query is received by the server and decrypted and decompressed. The server 18 sends the data to the programming interface 26, such that search engine 28 can for compare and match the transmitted data stream to the provided selected searchable data [i.e., creating the “searchable file-based data stream”]; Burns, [0065], see the user interface 42, particularly the GUI prompts the user to provide input, such as a patient's name, or a prescription [i.e., using broadest reasonable interpretation/BRI, “read access operations on a file by the client”]. The user indents the buttons or soft keys on the input/output device 40, activating the recording apparatus. The user orally speaks the requested information into the user interface 42. The recording apparatus records the data to a data stream. Notably, the recorded audible stream need not be a physical file, but can be a buffered stream. It is contemplated that the recorded audible stream can be any type of stream interfaceable with the input/output device 40; Burns, [0024], see it is contemplated that the client and server can communicate over, a Local Area Network Systems (LANS), World Area Network system (WANS), satellite systems or any other network systems [i.e., “network data stream”] known to those skilled in the art; Burns, [0066], see the recorded data stream, and data query, are encrypted and compressed according to known encryption and compression algorithms and transmitted to the connected server 18. During the execute method, the user interface 42 sends a data query requiring that the server 18 compare the recognized data generated by the search engine 28 to information contained in the database 34; Burns, [0068], see the SAPI engine 28 returns the appropriate recognized matching information that matches the transmitted data to the server 18. For example, if the user's spoken words were “John Doe,” the recognition engine 28 would return matching data in the database that the recognition engine believes matches the spoken words, such as for example, “John Doe” “Jonathan Doe” or “Jane Doe.”; Burns, [0069], see the server 18 verifies the matching recognized data by comparing the data to the information stored in the selected database 34. The database 34 uses a comparison engine to compare the matching recognized data to data contained in the database. The server retrieves the results based on the comparison to the database. The server then transmits the recognized matching data and the data query results. In this example, the database only contains a patient named “John Doe” and therefore only returns the result “John Doe.”; and Burns, [0070], see the verified matching data, in this case “John Doe,” is then encrypted and compressed for wireless transmission back to the client 12 [i.e., where the encrypted and compressed verified matching data is decrypted and decompressed at the client making the them searchable]),
transmitting the network data stream containing the file to the client, the network data stream not being initially searchable for the client (See Burns, [0024] above where client and server can communicate over, a Local Area Network Systems (LANS), World Area Network system (WANS); Burns, [0069] above where the server retrieves the results based on the comparison to the database. The server then transmits the recognized matching data and the data query results [i.e., the client]; and Burns, [0070] above where the verified matching data, in this case “John Doe,” is then encrypted and compressed for wireless transmission back to the client 12 [i.e., where the encrypted and compressed verified matching data is decrypted and decompressed at the client making the them searchable, which means the data was not searchable before]) and
during reception of the network data stream at the client, translating the network data stream into the searchable file-based data stream on the basis of the read access operations monitored on the client (Burns, [0038], see the server 18 is connected to the client 12 using wireless communication protocols known to those skilled in the art. The server 18 includes a messaging or communicating mechanism, an encrypting/de-encrypting mechanism, a compression/decompression mechanism, an interface for the communicating with the programming interface and a database interface; Burns, [0024], see it is contemplated that the client and server can communicate over, a Local Area Network Systems (LANS), World Area Network system (WANS), satellite systems or any other network systems [i.e., “network data stream”] known to those skilled in the art; Burns, [0040], see the encrypting/deencrypting mechanism [i.e., using BRI, the encrypting/deencrypting is interpreted as “translating”] provides a secure, private data transmission with the input/output device 40 [i.e., makes the data stream searchable]. The encrypting/deencrypting uses algorithms or methods, which correspond algorithms and methods used by the client 12, such that the server 18 and client 12 can communicate; Burns, [0043], see the selected searchable data 30 is provided to the programming interface 26, such that the recognition engine 28 can generate a stream of matching recognized data 30. The matching recognized data is generated by searching the selected searchable data for matching data elements contained in the transmitted stream and creating a matching data stream containing those matching [i.e., using BRI, where the matching is interpreted as “read access operations monitored on the client”] data elements [i.e., creating a “searchable file-based data stream on the basis of the read access operations monitored on the client … occurring on the basis of the read access operations monitored”]; and Burns, [0046], see the data search engine 28 searches the data contained in the selected searchable data 30 for matching information contained in the transmitted data stream, to create a data element of recognized matching data [i.e., creating a “searchable file-based data stream on the basis of the read access operations monitored on the client … occurring on the basis of the read access operations monitored”]),
Burns does not appear to explicitly disclose the network data stream being a continuous data stream that transfers the file continuously from an initial reading position within the file that has been indicated by an initial read access operation and only the initial read access operation identifies the file and the monitoring comprises storing the initial read access operation;
the reading position not being moveable forward or backward in the file after the initial read access operation;
the translating by the client being effect by comparing a current data position of the continuous data stream with a current reading position within the continuous data stream that is indicated by a current read access operation; and
if the current reading position is different than the current data position, replacing the current read access operation with a modified read access operation on the basis of an initial read access operation by the client and the current reading position.
Reim discloses the network data stream being a continuous data stream that transfers the file continuously from an initial reading position within the file that has been indicated by an initial read access operation and only the initial read access operation identifies the file and the monitoring comprises storing the initial read access operation (Reim, [0037], see “… The data ingestion module 164 can receive the streamed files [i.e., where the initial reading position is the beginning of the first file and where continuous streaming occurs when the files are very large/long and the ingestion process is still ongoing] from the different topics from the streaming platform 160. The data ingestion module 164 can read the datasets in the log lines of the files from each respective topic, map the datasets from the log lines into fields of a common (normalized) format, transform the datasets [i.e., where the “read access operations” are being interpreted as the reading and mapping instructions that “transform the datasets”], and load the datasets for storage in the data store database 140. …” see the data is mapped into fields of a common (normalized) format, the datasets transformed, and loaded in the data store database 140, and through the mapped fields the data is searchable; and Reim, [0039], see the files are downloaded from the respective locations and streamed to a streaming platform 160 (i.e., Apache Kafka) [i.e., where Apache Kafka continuous streaming refers to the capability of Apache Kafka to hand and process a continuous flow of real-time data, see Apache Kafka overview attached]. The streaming platform 160 can convert the files into a Java stream).
See claims 1 and 11 above for the motivation to combine.
The combination of Burns and Reim does not appear to explicitly disclose the reading position not being moveable forward or backward in the file after the initial read access operation;
the translating by the client being effect by comparing a current data position of the continuous data stream with a current reading position within the continuous data stream that is indicated by a current read access operation; and
if the current reading position is different than the current data position, replacing the current read access operation with a modified read access operation on the basis of an initial read access operation by the client and the current reading position.
Prahlad discloses the translating by the client being effect by comparing a current data position of the continuous data stream with a current reading position within the continuous data stream that is indicated by a current read access operation (See below); and
if the current reading position is different than the current data position, replacing the current read access operation with a modified read access operation on the basis of an initial read access operation by the client and the current reading position (Prahlad, [0150], see the data structure 520 consists of one or more stream headers 522 and stream data 524 [i.e., representing how to read the “network data stream”]. The stream header 522 describes a data object contained in an “N” file 506 or an “S” file 508 (e.g., its location, its size, an offset within the file, etc.). The stream data 524 contains the pointer to the data object contained in the “N” file 506 or the “S” file 508 [i.e., “current reading position is different than the current data position” and where the pointer “replacing the current read access operation with a modified read access operation” and where the insertion of the pointer is being interpreted as the “replacing the current read access operation”, where the previous read point is replaced with the new pointer in the read access operation]. For example, the pointer may give its location within the “N” file 506 or the “S” file 508. The location of the data object may be given by offsets within the “N” file 506 or the “S” file 508. For example, its location may be given by a starting offset, and its length or size. As another example, its location may be given by a starting offset and an ending offset [i.e., where the starting offset discloses “current reading position is different than the current data position”]. As previously mentioned, the data object may be in an “S” file 508 in another chunk folder, and the stream data 524 would point to this “S” file in the other chunk folder (e.g., give its location in the “S” file in the other chunk folder) …).
See claims 1 and 11 above for the motivation to combine.
The combination of Burns, Reim and Prahlad does not appear to explicitly disclose the reading position not being moveable forward or backward in the file after the initial read access operation.
Barton discloses the reading position not being moveable forward or backward in the file after the initial read access operation (Barton, [0031], see the Linear Cache (204) is a general device for buffering the information contained in a stream of digital information, such that the data in the cache can be viewed as a snapshot of the continuous stream of digital data; Barton, [0059], see the forward function is implemented by moving the current block indicator forward through the cache by one block for each event generated by the Stream Clock; and Barton, [0063], see the reverse function is implemented by moving the current block indicator backwards through the cache by one block for each clock event generated by the SC.)
See claim 12 above for the motivation to combine.
Allowable Subject Matter
Claim(s) 7 (and similarly claim(s) 16 and 19) is/are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
– O’Brien et al., 2010/0185614 for shared storage resource;
– Chung, 2003/0084152 for read-only storage device;
– Mockett, 2007/0266170 to interactive, rich-media delivery over an IP network using synchronized unicast and multicast;
– Motlagh, 2023/0177481 for extensible, low-code integration platform; and
– Bowman et al., DE 112016001075 for distributed saving and recalling data sets.
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.
Point of Contact
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HUBERT G CHEUNG whose telephone number is (571) 270-1396. The examiner can normally be reached M-R 8:00A-5:00P EST; alt. F 8:00A-4:00P EST.
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, Neveen Abel-Jalil can be reached at (571) 270-0474. 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.
HUBERT G. CHEUNG
Assistant Examiner
Art Unit 2152
Examiner: Hubert Cheung
/Hubert Cheung/Assistant Examiner, Art Unit 2152Date: January 5, 2025
/NEVEEN ABEL JALIL/Supervisory Patent Examiner, Art Unit 2152