DETAILED ACTION
Claims 1-20 are pending in this application.
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 .
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-5, 8-12, and 15-19 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 20210182267 A1 to Andreakis et al. in view of U.S. Pub. No. 20200034076 A1 to Zentz et al. and further in view of C.N. No. 104579889 A to Niu et al.
As to claim 1, Andreakis teaches a system comprising:
a processor (CPU 604); and
a non-transitory computer-readable medium (System Disk 606) comprising instructions that are executable by the processor to cause the processor to:
receive, from a data warehouse (Source Datastore(s) 120/Source Database(s) 121), a data stream (Log Event(s) 128) at a storage service (Sink datastore(s) 160/Derived Datastore(s) 161) (“…Change log 127 includes any technically feasible history of actions executed or performed on source datastore(s) 120 or the like. In some embodiments, change log 127 includes a log of one or more log event(s) 128 reflecting one or more changes in source datastore(s) 120 (e.g., changed rows, changed column schema, or the like). In some embodiments, the change log 127 includes a linear history of committed changes and non-stale reads associated with source datastore(s) 120…In some embodiments, log event(s) 128 include any event emitted by source datastore(s) 120 based on changes to rows, columns, or the like. In some embodiments, the log event(s) 128 may be emitted in real-time. In some embodiments, log event(s) 128 are of one or more types including create, update, delete, or the like. In some embodiments, log event(s) 128 are associated with one or more attributes including a log sequence number (LSN), the column values at the time of the operation (e.g., column title at a given point in time or the like), the schema that applied at the time of the operation, the full pre and post image of the row from the time of the change, a link to the last log record, type of database log record, information associated with the change that triggered the log record to be written, or the like…Derived datastore(s) 161 include any technically feasible storage infrastructure storing data derived from source datastore(s) 120. In some embodiments, derived datastore(s) 161 include one or more heterogeneous datastores, one or more relational databases, one or more file systems, one or more distributed datastores, one or more directory services, one or more active databases, one or more cloud databases, one or more data warehouses, one or more distributed databases, one or more embedded database systems, one or more document-oriented databases, one or more federated database systems, one or more array database management systems, one or more real-time databases, one or more temporal databases, one or more logic databases, or the like…” paragraphs 0048/0049/0051);
receive, at a first function of a first computing service, one or more notifications (Change Log 127/Log Events 128) (“…Output writer 144 includes any technically feasible write configured to collect one or more events and write to an output such as sink datastore(s) 160 or the like. In some embodiments, log and dump events are sent to the output using a non-blocking operation or the like. In some embodiments, output writer 144 runs its own thread and collects one or more events in an output buffer prior to writing the events to an output in order. In some embodiments, output writer includes retrieved schema 153 or an associated schema identifier in the output…In some embodiments, the output buffer is stored in memory. In some embodiments, output writer 144 includes an interface configured to plugin to any output such as sink datastore(s) 160…In some embodiments, output writer 144 includes an event serializer configured to serialize events into a customized format prior to appending the events to an output buffer, writing events to an output, or the like. In some embodiments, output writer 144 includes an interface to allow plugin of a custom formatter for serializing events in a customized format. In some events, output writer 144 appends events to an output buffer using one thread, and uses another thread to consume the events from the output buffer and send them to the output…” paragraphs 0061-0063), wherein each notification is generated when a file containing data from the data stream is created in the storage service (Change Log 127/Log Events 128) (“…Change log 127 includes any technically feasible history of actions executed or performed on source datastore(s) 120 or the like. In some embodiments, change log 127 includes a log of one or more log event(s) 128 reflecting one or more changes in source datastore(s) 120 (e.g., changed rows, changed column schema, or the like). In some embodiments, the change log 127 includes a linear history of committed changes and non-stale reads associated with source datastore(s) 120…In some embodiments, log event(s) 128 include any event emitted by source datastore(s) 120 based on changes to rows, columns, or the like. In some embodiments, the log event(s) 128 may be emitted in real-time. In some embodiments, log event(s) 128 are of one or more types including create, update, delete, or the like. In some embodiments, log event(s) 128 are associated with one or more attributes including a log sequence number (LSN), the column values at the time of the operation (e.g., column title at a given point in time or the like), the schema that applied at the time of the operation, the full pre and post image of the row from the time of the change, a link to the last log record, type of database log record, information associated with the change that triggered the log record to be written, or the like…” paragraphs 0048/0049);
in response to each notification received at the first function, pass, by the first function, a message to a queue (output buffer/non-blocking) (“…Output writer 144 includes any technically feasible write configured to collect one or more events and write to an output such as sink datastore(s) 160 or the like. In some embodiments, log and dump events are sent to the output using a non-blocking operation or the like. In some embodiments, output writer 144 runs its own thread and collects one or more events in an output buffer prior to writing the events to an output in order. In some embodiments, output writer includes retrieved schema 153 or an associated schema identifier in the output…In some embodiments, output writer 144 includes an event serializer configured to serialize events into a customized format prior to appending the events to an output buffer, writing events to an output, or the like. In some embodiments, output writer 144 includes an interface to allow plugin of a custom formatter for serializing events in a customized format. In some events, output writer 144 appends events to an output buffer using one thread, and uses another thread to consume the events from the output buffer and send them to the output…” paragraphs 0061/0063);
receive, at a second computing service, one or more messages from the queue (“…Output writer 144 includes any technically feasible write configured to collect one or more events and write to an output such as sink datastore(s) 160 or the like. In some embodiments, log and dump events are sent to the output using a non-blocking operation or the like. In some embodiments, output writer 144 runs its own thread and collects one or more events in an output buffer prior to writing the events to an output in order. In some embodiments, output writer includes retrieved schema 153 or an associated schema identifier in the output…In some embodiments, output writer 144 includes an event serializer configured to serialize events into a customized format prior to appending the events to an output buffer, writing events to an output, or the like. In some embodiments, output writer 144 includes an interface to allow plugin of a custom formatter for serializing events in a customized format. In some events, output writer 144 appends events to an output buffer using one thread, and uses another thread to consume the events from the output buffer and send them to the output…” s 0061/0063);
retrieve, by the second function, data from one or more files within the storage service, based on the address in each of the one or more messages (Output Writer 144); and
write, by the second function, the data from the one or more files to a database (Sink datastore(s) 160/output) (“…Output writer 144 includes any technically feasible write configured to collect one or more events and write to an output such as sink datastore(s) 160 or the like. In some embodiments, log and dump events are sent to the output using a non-blocking operation or the like. In some embodiments, output writer 144 runs its own thread and collects one or more events in an output buffer prior to writing the events to an output in order. In some embodiments, output writer includes retrieved schema 153 or an associated schema identifier in the output…” paragraph 0061).
Andreakis is silent with reference to the message comprising an address of a respective file within the storage service and a message group identification (ID) selected from a range,
wherein the invocation of the second function to which each message is routed is based on the message group identification (ID) and
receive, at a second computing service having a plurality of invocations of a second function, one or more messages, wherein each particular message of the one or more messages is routed to a particular invocation of the second function is based on the message group identification (ID) of the particular message of the one or more messages.
Zentz teaches the message (write commands) comprising an address (allocated block) of a respective file within the storage service (SSDs) (“…An embodiment of a data storage system may operate in accordance with one or more storage protocols or standards, such as the SCSI standard or protocol or the NVMe (Non-Volatile Memory Express) standard or protocol. Write Streams are features included in standards, such as the NVMe and SCSI standards, for use with SSDs, such as those providing non-volatile backend physical storage on the data storage system. Write Streams generally allow write commands to an SSD to be tagged with an identifier which is used to optimize data placement of the write data on the storage media of the SSD. The identifier may be assigned to a write stream where a group of related data segments have the same identifier. Related data having the same identifier may be grouped together so that when writing to SSD physical media, processing by the SSD places related data (having the same identifier) together, such as in the same allocated block, so that such data may also be erased together as a group. Thus, data associated with the same Write Stream is expected to be invalidated (e.g., via a data operation such as update/write, deallocation, etc.) at the same time. Use of Write Streams allows for SSD block allocation where related data having a similar expected data lifetime may be placed in the same erase block thereby reducing write amplification (e.g., such as due to rewriting data and garbage collection when performing space reclamation). Write Streams are intended to improve the performance and endurance of an SSD over its lifetime…” paragraph 0039) and a message group ID selected from a range (“…In step 808, processing is performed to randomly assign each extent ID of the extent ID range to a RAID group ID uniquely associated with one of the RAID groups in the system…” paragraph 0073) and
wherein the invocation of the second function to which each message is routed is based on the message group identification (ID) (Write Streams generally allow write commands to an SSD to be tagged with an identifier which is used to optimize data placement of the write data on the storage media of the SSD) (“…An embodiment of a data storage system may operate in accordance with one or more storage protocols or standards, such as the SCSI standard or protocol or the NVMe (Non-Volatile Memory Express) standard or protocol. Write Streams are features included in standards, such as the NVMe and SCSI standards, for use with SSDs, such as those providing non-volatile backend physical storage on the data storage system. Write Streams generally allow write commands to an SSD to be tagged with an identifier which is used to optimize data placement of the write data on the storage media of the SSD. The identifier may be assigned to a write stream where a group of related data segments have the same identifier. Related data having the same identifier may be grouped together so that when writing to SSD physical media, processing by the SSD places related data (having the same identifier) together, such as in the same allocated block, so that such data may also be erased together as a group. Thus, data associated with the same Write Stream is expected to be invalidated (e.g., via a data operation such as update/write, deallocation, etc.) at the same time. Use of Write Streams allows for SSD block allocation where related data having a similar expected data lifetime may be placed in the same erase block thereby reducing write amplification (e.g., such as due to rewriting data and garbage collection when performing space reclamation). Write Streams are intended to improve the performance and endurance of an SSD over its lifetime…” paragraph 0039)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Andreakis with the teaching of Zentz because the teaching of Zentz would improve the system of Andreakis by using Write Streams that allows write commands to an SSD to be tagged with an identifier which is used to optimize data placement of the write data on the storage media of the SSD (Zentz paragraph 0039).
Niu teaches receive, at a second computing service having a plurality of invocations of a second function, one or more messages, wherein each particular message of the one or more messages is routed to a particular invocation of the second function (public application program interface) is based on the message group identification (ID) (identification) of the particular message of the one or more messages (the first call message comprises identification and a public application program interface) (“…1010, first device sends first call message to the NFV device, the first call message comprises identification and a public application program interface (English full name of application program-number interface is the English abbreviation API) identification of a second NF of requesting to call the first device, indicates that the first device requests through the common API for the second NF… by performing a 1010-1020, NFV middleware device receiving first calling message sent by the device, and according to the common API a first call in the message identification and second identification inquiring the first corresponding relation, determining the call identification of the first second private API, so as to use the first private API to call the second NF. Thus, the first device can pass through the common API cannot directly call the second NF of the transfer to the second NF…NFV device 40 includes a first receiving unit 41, a determining unit 42 and a transferring unit 43. the first receiving unit 41 is configured to receive a first call message sent by the first device, identification of the NF in the first call message carries identification and the first device public API of request call. the first call message indicates that the first device requests to use the common API to invoke the second NF. the determining unit 42 is used for the first adjustment in the public API carried in the message of the identification, the first call message carried by the second identification and the the first corresponding relation stored in the NFV device determining the identification of the first private API, wherein the first corresponding relationship comprises the public API identification, the second identification and the first private API identification between the corresponding relationship, the first private API is used when the NFV middleware device transferring the second API. the calling unit 43 used in the first private API corresponding to identification of the first private API calling the second NF…” paragraphs 0057/0067/0109).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Andreakis and Zentz with the teaching of Niu because the teaching of Niu would improve the system of Andreakis and Zentz by providing a technique for uniquely associating messages to the operations or functions that they are designed to execute in order to optimally carry out the tasks.
As to claim 2, Andreakis teaches the system of claim 1, wherein the storage service comprises an event-driven object storage system (Sink datastore(s) 160) (“…Sink datastore(s) 160 include any technically feasible storage infrastructure for storing and managing collections of data. In some embodiments, sink datastore(s) 160 include one or more heterogeneous datastores, one or more relational databases, one or more file systems, one or more distributed datastores, one or more directory services, one or more active databases, one or more cloud databases, one or more data warehouses, one or more distributed databases, one or more embedded database systems, one or more document-oriented databases, one or more federated database systems, one or more array database management systems, one or more real-time databases, one or more temporal databases, one or more logic databases, or the like. In some embodiments, sink datastore(s) 160 operate on a plurality of servers, a plurality of storage devices, or the like. The server may be a standalone server, a cluster or “farm” of servers, one or more network appliances, or the like. In some embodiments, sink datastore(s) 160 include data managed by one or more teams, one or more business entities, or the like. In some embodiments, sink datastore(s) 160 include any downstream application configured to propagate received events (e.g., stream processing application, data analytics platform), search index, cache, or the like. Sink datastore(s) 160 includes, without limitation, derived datastore(s) 161, stream(s) 162 and application programming interfaces (API(s)) 163…” paragraph 0050).
As to claim 3, Andreakis teaches the system of claim 2, wherein the first function is triggered to pass messages to the queue based on event data generated by the storage service, the event data comprising the one or more notifications (output buffer/non-blocking) (“…Output writer 144 includes any technically feasible write configured to collect one or more events and write to an output such as sink datastore(s) 160 or the like. In some embodiments, log and dump events are sent to the output using a non-blocking operation or the like. In some embodiments, output writer 144 runs its own thread and collects one or more events in an output buffer prior to writing the events to an output in order. In some embodiments, output writer includes retrieved schema 153 or an associated schema identifier in the output…In some embodiments, output writer 144 includes an event serializer configured to serialize events into a customized format prior to appending the events to an output buffer, writing events to an output, or the like. In some embodiments, output writer 144 includes an interface to allow plugin of a custom formatter for serializing events in a customized format. In some events, output writer 144 appends events to an output buffer using one thread, and uses another thread to consume the events from the output buffer and send them to the output…” paragraphs 0061/0063).
As to claim 4, Andreakis teaches the system of claim 1, wherein the storage service, and the database are hosted in a cloud-based system (Sink datastore(s) 160) (“…Sink datastore(s) 160 include any technically feasible storage infrastructure for storing and managing collections of data. In some embodiments, sink datastore(s) 160 include one or more heterogeneous datastores, one or more relational databases, one or more file systems, one or more distributed datastores, one or more directory services, one or more active databases, one or more cloud databases, one or more data warehouses, one or more distributed databases, one or more embedded database systems, one or more document-oriented databases, one or more federated database systems, one or more array database management systems, one or more real-time databases, one or more temporal databases, one or more logic databases, or the like. In some embodiments, sink datastore(s) 160 operate on a plurality of servers, a plurality of storage devices, or the like. The server may be a standalone server, a cluster or “farm” of servers, one or more network appliances, or the like. In some embodiments, sink datastore(s) 160 include data managed by one or more teams, one or more business entities, or the like. In some embodiments, sink datastore(s) 160 include any downstream application configured to propagate received events (e.g., stream processing application, data analytics platform), search index, cache, or the like. Sink datastore(s) 160 includes, without limitation, derived datastore(s) 161, stream(s) 162 and application programming interfaces (API(s)) 163…” paragraph 0050).
.
As to claim 5, Zentz teaches the system of claim 1, however it is silent with reference to wherein the message group ID is randomly selected from the range (“…In step 808, processing is performed to randomly assign each extent ID of the extent ID range to a RAID group ID uniquely associated with one of the RAID groups in the system…” paragraph 0073).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Andreakis and Niu with the teaching of Zentz because the teaching of Zentz would improve the system of Andreakis and Niu by using Write Streams that allows write commands to an SSD to be tagged with an identifier which is used to optimize data placement of the write data on the storage media of the SSD (Zentz paragraph 0039).
As to claims 8 and 15, see the rejection of claim 1 above.
As to claims 9 and 16, see the rejection of claim 2 above.
As to claims 10 and 17, see the rejection of claim 3 above.
As to claims 11 and 18, see the rejection of claim 4 above.
As to claims 12 and 19, see the rejection of claim 5 above.
Claims 6, 13 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 2021/0182267 A1 to Andreakis et al. in view of U.S. Pub. No. 2020/0034076 A1 to Zentz et al. and further in view of C.N. No. 104579889 A to Niu et al. as applied to claims 1, 8 and 15 above, and further in view of U.S. Pub. No. 2017/0161288 A1 to Feldman et al.
As to claim 6, Andreakis as modified by Zentz and Niu teaches the system of claim 1, however it is silent with reference to wherein the queue is a first-in-first-out (FIFO) queue.
Feldman teaches wherein the queue is a first-in-first-out (FIFO) queue (FIFO memory) (“…As illustrated by FIG. 1, data storage device 101 comprises data storage 104 (e.g., a block device, a file system, a network block device, a virtual block device, etc.), file event notification component 120, and analytics engine component 130. In this regard, file event notification component 120 (e.g., inotify, a filter driver, etc.) can detect accesses, e.g., activity 102, of respective files of data storage 104. For example, in embodiment(s), activity 102 can comprise processes related to creating a file in data storage 104, modifying the file, reading the file, deleting the file, opening the file, closing the file, etc. In other embodiment(s), file event notification component 120 can detect properties, e.g., an I/O latency of an access of the accesses, a data throughput associated with the access, etc.
[0037] Further, in response to detecting activity 102, file event notification component 120 can generate message file-system event representing an access corresponding to activity 102, and send the file-system event to analytics engine component 130. In turn, analytics engine component 130 can receive the file-system event from file event notification component 120, generate a subscriber event message representing the file-system event, and store the subscriber event message in a queue (see e.g., event queue 222 below), a FIFO memory, etc….” paragraphs 0036/0037).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Andreakis, Zentz and Niu with the teaching of Feldman because the teaching of Feldman would improve the system of Andreakis, Zentz and Niu by providing a data structure (often, specifically a data buffer) where the oldest (first) entry, or "head" of the queue, is processed first.
As to claims 13 and 20, see the rejection of claim 6 above.
Claims 7 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Pub. No. 20210182267 A1 to Andreakis et al. in view of U.S. Pub. No. 2020/0034076 A1 to Zentz et al. and further in view of C.N. No. 104579889 A to Niu et al. as applied to claims 1 and 8 above, and further in view of U.S. Pub. No. 2018/0067864 A1 to Park et al.
As to claim 7, Andreakis as modified by Zentz and Niu teaches the system of claim 1, however it is silent with reference to wherein a desired throughput can be adjusted by controlling a number of routines of each invocation of the second function that can simultaneously write to the database.
Park teaches wherein a desired throughput can be adjusted (Step 405) by controlling a number of routines of each invocation of the second function that can simultaneously write to the database (remote storage unit/cloud storage) (‘…As described above, each writer may generate an individual event stream. In one embodiment, the messages from the writers (i.e., individual event stream) may be stored in a remote storage unit, for example a cloud storage. The remote storage unit may also store a history of readers' subscription list of writers. Therefore, a replay of a reader's past operation (i.e., what messages the reader saw) may be reconstructed. In one embodiment, the remote storage unit may be integrated with the repeater block components…FIG. 4A illustrates a flow diagram of receiving messages in accordance with an embodiment of the present invention. In one embodiment, the method of FIG. 4A may be performed by one of the readers 140.1-140.P of FIG. 1, or alternatively, it may be performed by another device. In step 405, the reader may set a list of writers to which it will listen. The writers on the list may be distributed across different locations in the distributed computing network. In step 410, the reader may receive messages from the writers on its list. In addition, the reader may also receive heartbeats from the writers on its list…” paragraphs 0028/0041).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claim invention to modify the system of Andreakis, Zentz and Niu with the teaching of Park because the teaching of Park would improve the system of Andreakis, Zentz and Niu by providing a technique for setting a list of writers for writing data messages to remote distributed storages and as such allowing for concurrency writing of data messages.
As to claim 14, see the rejection of claim 7 above.
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES E ANYA whose telephone number is (571)272-3757. The examiner can normally be reached Mon-Fir. 9-6pm.
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, KEVIN YOUNG can be reached at 571-270-3180. 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.
/CHARLES E ANYA/Primary Examiner, Art Unit 2194
Prosecution Insights