Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
This action is responsive to claims filed on December 23, 2025. Claims 1, 8 and 15 have been amended. Claims 1-20 are presented for examination.
Response to Argument(s)
Applicant's argument(s) filed on December 23, 2025 with respect to the double patenting rejection has been noted. However, recent claim amendment does not appear to make the instant application patentably distinct over U.S. Patent No. 11,509,619. Therefore, the double patenting rejection is maintained but would be re-evaluated if/when the instant application is due for issue.
Applicant’s arguments with respect to claims 1-20 have been considered but are moot in view of the new ground(s) of rejections.
Authorization for Internet Communication
To expedite prosecution, filing a written authorization for internet communication is recommended. Doing so permits the USPTO to communicate using email to schedule interviews and/or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to email communications. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Claims 1-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over Claims 1-18 of U.S. Patent No. 11,509,619. Although the claims at issue are not identical, they are not patentably distinct from each other because the instant application claims are broader than the U.S. Patent.
Each of the instant application claims (1 & 8) is broader in scope than the corresponding claims (1 & 10) in the U.S. Patent. Taking said claims in the instant application, as an exemplary, to compare to said claims in the U.S. Patent (see comparison table below). The rest of the instant application claims recite similar features as those cited in the U.S. Patent.
Therefore, it would have been obvious to one of ordinary skill in the art at the time the invention was made to omit elements when the remaining elements perform as before. A person of ordinary skill could have arrived at the present claims by omitting the details of said U.S. Patent claims. See In re Karlson (CCPA) 136 USPQ 184, decided January 16, 1963 (“Omission of element and its function in combination is obvious expedient if remaining elements perform same function as before”).
An exemplary table to show similarity among the conflicting claims.
Instant Application
U.S. Patent No. 11,509,619
1.A method comprising:
responsive to receiving an indication that streaming data was not delivered,
receiving, at a distributed message queue, a copy of a message that failed to deliver to a streaming data platform, the copy of the message including the streaming data;
publishing, by the distributed message queue, the copy of the message to the streaming data platform;
determining, by the distributed message queue, whether the copy of the message is received by the streaming data platform; and
in response to the copy of the message not being received by the streaming data platform,
re-publishing the copy of the message from the distributed message queue to the streaming data platform after a configurable period of time has passed since a most recent time the distributed message queue published the copy of the message.
A computer-implemented method, comprising:
receiving, by a service application, data from a data service provider;
communicating, by the service application, one or more messages comprising the data to a streaming data platform, wherein the service application initially communicates the one or more messages directly to the streaming data platform without utilizing a cloud-based queue;
detecting, by the service application, a failure of delivery of a message of the one or more messages to the streaming data platform;
communicating, by the service application and via an application programming interface (API), the message to a cloud-based distributed message queue service, wherein the message is communicated to the cloud-based distributed message queue service in response to the failure of delivery and stored in the cloud-based queue of a cloud-based distributed message queue system;
publishing, by a cloud-based distributed message queue service client of the cloud-based distributed message queue system, the message to the streaming data platform;
determining, by the cloud-based distributed message queue service client, whether the message published to the streaming data platform was successfully or unsuccessfully received by the streaming data platform; and
retrying publishing, by the distributed message queue service client, of the message to the streaming data platform when publication of the message is unsuccessful.
8. A computing system comprising:
a memory for storing executable instructions thereon; a processing circuit for executing the instructions, which when executed cause the processing circuit to:
responsive to receiving an indication that streaming data was not delivered,
store, in a message queue, a copy of streaming data that failed to deliver to a streaming platform;
poll the message queue to receive the copy of the streaming data;
send the copy of the streaming data to the streaming platform;
determine whether the copy of the streaming data is delivered to the streaming platform; and
in response to the copy of the streaming data not being delivered to the streaming platform, store the copy of the streaming data in the message queue for a predetermined period of time before re-sending the copy of the streaming data to the streaming platform.
10. A system, comprising:
memory; and
one or more processors coupled with the memory, the one or more processors configured to:
receive, by a service application, data from a data service provider;
communicate, by the service application, a plurality of messages comprising the data directly to a streaming data platform without utilizing a cloud-based queue of a cloud-based distributed message queue system unless one or more failures are detected;
detect, by the service application, a failure of delivery of at least one of the plurality of messages to the streaming data platform;
communicate, by the service application, the at least one of the plurality of messages to a cloud-based distributed message queue service of the cloud-based distributed message queue system, wherein the at least one of the plurality of messages are communicated to the cloud-based distributed message queue service in response to the failure of delivery and stored in the cloud-based queue of the cloud-based distributed message queue system for publication to the streaming data platform;
publish, by a cloud-based distributed message queue service client of the cloud-based distributed message queue system, the at least one of the plurality of messages to the streaming data platform;
determine, by the cloud-based distributed message queue service client, whether each of the at least one of the plurality of messages published to the streaming data platform was successfully or unsuccessfully published to the streaming data platform; and
retry the publication, by the distributed message queue service client, of each unsuccessfully published messages of the at least one of the plurality of messages to the streaming data platform.
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.
Claims 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Siebel et al “Siebel”, US-PGPub. No. 20170006135 in view of Roowalla et al “Roowalla”, US-PGPub. No. 20210184848 and in further view of Vogtmeier et al “Vogtmeier”, US-PGPub. No. 20020150045.
As per claims 1, 8 and 15 , Siebel teaches a method, a non-transitory computer-readable storage medium and a computing system comprising:
a memory (Paragraph(s) [0609]) for storing executable instructions thereon;
a processing circuit for executing the instructions (Paragraph(s) [0247]), which when executed cause the processing circuit to:
store, in a message queue, a copy of streaming data that failed to deliver to a streaming platform (Paragraph(s) [0317], [0326]; the distributed queues 1606 may include redundant, scalable infrastructure for guaranteed message receipt and delivery. The distributed queues 1606 may provide concurrent access to messages and/or high reliability in sending and retrieving messages. The distributed queues 1606 may include multiple readers and writers so that there are multiple components of the system that are enabled to send and receive messages in real-time with no interruptions. The distributed queues 1606 may be interconnected and configured to provide a redundant, scalable infrastructure for guaranteed message recipient and delivery. The prior art further discloses the distributed queues 1606 may operate as durable queues that retain a copy of messages. In one embodiment, a copy of the messages must be kept on the file system for an agreed upon period of time);
poll the message queue to receive the copy of the streaming data (Paragraph(s) [0326]; the distributed queues 1606 may provide concurrent access to messages and/or high reliability in sending and retrieving messages);
send the copy of the streaming data to the streaming platform (Paragraph(s) [0234], [0326], [0344]);
determine whether the copy of the streaming data is delivered to the streaming platform (Paragraph(s) [0340]; if the message is not received correctly, a NACK is sent back to tell the concentrator to resend the message); and
in response to the copy of the streaming data not being delivered to the streaming platform, store the copy of the streaming data in the message queue for a predetermined period of time before re-sending the copy of the streaming data to the streaming platform (Paragraph(s) [0329], [0344], [0369]; if the message is invalid, it should be placed on a dead letter queue for later analysis and a NACK is sent back to tell the concentrator to resend the message. The prior art further discloses a copy of the messages may be kept on a file system for an agreed upon period of time for troubleshooting purposes and in case of disputes with customers or third parties (Paragraph [0376]). In addition, the prior discloses based on the message type, the communication/retry logic may place a message into an inbound queue, wherein the message will await processing. When data or messages need to be sent to one or more of the data sources 208, messages may be placed in the outbound queues. When available, the communication/reply logic may provide a message to the message sender for communication to a destination data source 208 (Paragraph [0158])).
Siebel fails to expressly teach but Roowalla discloses in response to the copy of the streaming data not being delivered, the streaming data remains in the message queue for a predetermined period of time before re-sending the copy of the streaming data (Paragraph(s) [0056-0057]; if a record worker 416, 418, 420 encounters a failure or error during execution, the respective record worker may roll back the entire update, generate and publish a retry message that identifies the failure to retry queue 424. Retry worker 426 may retrieve the retry message and republish the failure message to a queue 410, 412, 414 for retry and store a retry count in database 428…when a maximum number of retries are exhausted, the retry worker will generate and publish a failure message and the corresponding failure message may be published to dead letter queue 430)
Siebel in view of Roowalla fail to expressly teach but Vogtmeier teaches responsive to receiving an indication that streaming data was not delivered, receiving a copy of a message that failed to deliver to a streaming data platform, the copy of the message including the streaming data (Paragraph(s) [0010]; in order to ensure completely correct transmission of all the data nevertheless, a copy of each transmitted data packet is stored in the buffer before the transmission. The copy can then be called up again as required at a later point in time in order to retransmit the corresponding data packet if the first attempt at transmission should not have been successful. Such a renewed transmission of an unsuccessfully transmitted data packet takes place when the acknowledge signal concerning this data packet from the receiver indicates a failure of the transmission. Vogtmeier further teaches if the acknowledge signal from the receiver indicates that a specific data packet has been successfully transmitted, there is no longer a need for further storage of this data packet in the buffer of the transmitter. After arrival of such an acknowledge signal, the transmitter, therefore, erases the corresponding data packet from the buffer such that the memory location is available again for accepting new data packets (Paragraph(s) [0011])).
Therefore, it would have been obvious to one of the ordinary skill in the art before the effective filing date of the applicants' invention to combine the teachings of Siebel, Roowalla and Vogtmeier in order to provide an efficient way of insuring successful delivery of failed/undelivered data/messages to intended recipients.
As per claims 2, 9 and 16, Siebel teaches wherein determining whether the copy of the message is received by the streaming data platform includes receiving or determining a delivery timeout of a predetermined amount of time, or determining a connectivity failure (Paragraph(s) [0210], [0329], [0340]).
As per claim 3, Siebel teaches sending, by the distributed message queue, an alert message to a computing device in communication with the distributed message queue indicating that the copy of the message is being re-published (Paragraph(s) [0311], [0580]).
As per claim 4, Siebel teaches triggering, by the distributed message queue, an alarm after a predetermined number of alert messages has been sent over a predetermined period of time (Paragraph(s) [0594]).
As per claims 5, 12 and 18, Siebel teaches wherein the distributed message queue includes:
an encrypted memory device to temporarily store the copy of the message (Paragraph(s) [0367], [0446]); and
a distributed message queue client configured to publish and re-publish the copy of the message (Paragraph(s) [0210], [0346]).
As per claims 6, 13 and 19, Siebel teaches wherein the method further comprises the distributed message queue client polling the encrypted memory device for the copy of the message and publishing or re-publishing the copy of the message as a single message or in a batch of messages (Paragraph(s) [0380]; the system architecture can publish individual messages or batches of messages to the integration service bus).
As per claim 7, Siebel teaches wherein the method further comprises the distributed message queue client determining that the re-published copy of the message did not reach the streaming data platform (Paragraph(s) [0340], [0344]); and
sending, by the distributed message queue client back to the encrypted memory device for storage for a predetermined period of time (Paragraph(s) [0352]).
As per claim 10, Siebel teaches wherein the processing circuit is further caused to re-send the copy of the streaming data to the streaming platform (Paragraph(s) [0158], [0340]).
As per claim 11, Siebel teaches wherein the processing circuit is further caused to trigger an alarm when re-sending the copy of the streaming data (Paragraph(s) [0594]).
As per claims 14 and 20, Siebel teaches wherein the processing circuit is configured to re-send the copy of the streaming data to the streaming platform until the processing circuit determines that the streaming platform has received the copy of the streaming data or until a second predetermined period of time has expired (Paragraph(s) [0329-0330], [0352], [0517]).
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 extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Mohamed Wasel whose telephone number is (571)272-2669. The examiner can normally be reached on Mon-Fri (8:00 am - 4:30 pm).
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Glenton Burgess can be reached on (571)272-3949. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/MOHAMED A. WASEL/Primary Examiner, Art Unit 2454