DETAILED ACTION
This action is a response to an application filed on 1/26/24 in which claims 1-20 are pending.
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.
Claim(s) 1 and 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bahis et al, EP 2 150 029 A1, herein Bahis and Dhamdhere et al. (Pub. No.: 2020/0068017), herein Dhamdhere.
As to claim 1, Bahis teaches a method comprising:
for each incoming request of the plurality of incoming requests:
generating an outgoing transaction identifier based on the address and the incoming transaction identifier (Bahis [0011] a first address associated with data is translated in a second address (outgoing transaction id) wherein the second address comprises a unique identifier based on source information); and
sending an outgoing request to a target device in the data processing network, the outgoing request having the outgoing transaction identifier, where outgoing transaction identifiers differ from one another (Bahis [0011] said data is forwarded using the second address [0018] the second address comprises at least one of the following: the first address, a transaction identifier, a random number, an identifier of a system)
Bahis does not teach
a common incoming transaction identifier
receiving a plurality of incoming requests at an interface of a data processing network from a manager device operably coupled to the interface, the plurality of incoming requests having a common incoming transaction identifier and each incoming request associated with a different address in the data processing network
However Dhamdhere does teach
a common incoming transaction identifier
receiving a plurality of incoming requests at an interface of a data processing network from a manager device operably coupled to the interface, the plurality of incoming requests having a common incoming transaction identifier and each incoming request associated with a different address in the data processing network (Dhamdhere [0062] Initially, data is received from a transmitting agent at a receiving agent (Operation 302). This initial data may include one or more data items (or a portion thereof) to be stored by the receiving agent, meta-data corresponding to the data items, header data, a notification, a message, an upload or file transfer request to the receiving agent and/or instructions or details relating to the request [0063] the received data includes a request and claim 4 transmitting each of the plurality of messages and claim 6 a same transaction identifier is included in each of the plurality of messages [0096] the data items are received via separate requests from different tenants (addresses))
It would have been obvious before the effective filing date of the claimed invention to combine the teachings of Bahis and Dhamdhere, because Dhamdhere teaches us [0049] In an example, the transmitting agent then transmits each portion of a data item separately to the receiving agent. Each portion is transmitted with a header that indicates that a portion is being transmitted, such as, the request, “X-Upload-Action32 ‘upload_data.’” Along with each portion of the data item, additional information may be transmitted in a header, a JSON object, or other data object. The additional information includes a transaction identifier, which indicates which portions belong to a same transaction and may be provided by the receiving agent to the transmitting agent. The additional information also includes a portion identifier and a filename, which identifies the portion and the data item, and is used by a receiving agent to aggregate the portions into complete data items. The additional information also includes a checksum, which is used by the receiving agent to verify successful receipt of the portion. Each portion is transmitted as a separate request to the receiving agent.
As to claim 4, the combination of Bahis and Dhamdhere teach the method of claim 1, where the plurality of incoming requests are ordered, further comprising: receiving responses to the outgoing requests at the interface (Dhamdhere [0083] a successful response is returned to the transmitting agent); and forwarding the responses to the master device in the same order as the incoming requests were received (Dhamdhere [0021] the data item is being produced or transmitted in an order in which the data item is being stored or retrieved)
It would have been obvious before the effective filing date of the claimed invention to combine the teachings of Bahis and Dhamdhere for the same reasons stated in claim 1.
Claim(s) 11, 14 and 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bahis Dhamdhere and Viola et al. (EP 3 185 159 A1), herein Viola.
As to claim 11, Bahis teaches a network interface configured to:
receive a plurality of incoming requests from a manager device of a data processing network, the plurality of incoming requests having a common incoming transaction identifier and each incoming request associated with a different address in the data processing network; and
for each incoming request of the plurality of incoming requests:
generate, an outgoing transaction identifier based on the address and the transaction identifier (Bahis [0011] a first address associated with data is translated in a second address wherein the second address comprises a unique identifier based on source information); and
send an outgoing request to a target device in the data processing network, the outgoing request having the outgoing transaction identifier, where the outgoing transaction identifiers generated differ from one another (Bahis [0011] said data is forwarded using the second address [0018] the second address comprises at least one of the following: the first address, a transaction identifier, a random number, an identifier of a system)
Bahis does not teach
a common incoming transaction identifier
receiving a plurality of incoming requests at an interface of a data processing network from a manager device operably coupled to the interface, the plurality of incoming requests having a common incoming transaction identifier and each incoming request associated with a different address in the data processing network
in an identification (ID) diversifier circuit of the interface,
However Dhamdhere does teach
a common incoming transaction identifier
receiving a plurality of incoming requests at an interface of a data processing network from a manager device operably coupled to the interface, the plurality of incoming requests having a common incoming transaction identifier and each incoming request associated with a different address in the data processing network (Dhamdhere [0062] Initially, data is received from a transmitting agent at a receiving agent (Operation 302). This initial data may include one or more data items (or a portion thereof) to be stored by the receiving agent, meta-data corresponding to the data items, header data, a notification, a message, an upload or file transfer request to the receiving agent and/or instructions or details relating to the request [0063] the received data includes a request and claim 4 transmitting each of the plurality of messages and claim 6 a same transaction identifier is included in each of the plurality of messages [0096] the data items are received via separate requests from different tenants (addresses))
It would have been obvious before the effective filing date of the claimed invention to combine the teachings of Bahis and Dhamdhere for the same reasons stated in claim 1.
Bahis nor Dhamdhere teach
in an identification (ID) diversifier circuit of the interface,
However Viola does teach
in an identification (ID) diversifier circuit of the interface (Viola [0128] In an embodiment, the remote system 21 may store the diversifier ID on its side. And during a transaction, the mobile application 18 may request the diversifier ID to the remote system 21 to generate the static key WB_KEK. In an embodiment, this generated static key WB_KEK is deleted after the computation of the cryptogram)
It would have been obvious before the effective filing date of the claimed invention to combine the teachings of Bahis, Dhamdhere and Viola, because Viola teaches us [0125] a static key WB_KEK may be derived from a master derivation key (MDK) associated with the key management server 23. This static key WB_KEK is associated with a diversifier ID. The diversifier ID may include information pertaining to the generation of the static key WB_KEK. For example, the diversifier ID may be used as a seed to generate its corresponding WB_KEK.
As to claim 19, Bahis teaches a non-transitory computer-readable medium to store computer-readable code for fabrication of a network interface configured to:
receive a plurality of incoming requests from a manager device of a data processing network, the plurality of incoming requests having a common incoming transaction identifier and each incoming request associated with a different address in the data processing network; and
for each incoming request of the plurality of incoming requests:
generate, in an identification (ID) diversifier circuit of the interface, an outgoing transaction identifier based on the address and the transaction identifier (Bahis [0011] a first address associated with data is translated in a second address wherein the second address comprises a unique identifier based on source information); and
send an outgoing request to a target device in the data processing network, the outgoing request having the outgoing transaction identifier, where the outgoing transaction identifiers differ from one another (Bahis [0011] said data is forwarded using the second address [0018] the second address comprises at least one of the following: the first address, a transaction identifier, a random number, an identifier of a system)
Bahis does not teach
a common incoming transaction identifier
receiving a plurality of incoming requests at an interface of a data processing network from a manager device operably coupled to the interface, the plurality of incoming requests having a common incoming transaction identifier and each incoming request associated with a different address in the data processing network
in an identification (ID) diversifier circuit of the interface,
However Dhamdhere does teach
a common incoming transaction identifier
receiving a plurality of incoming requests at an interface of a data processing network from a manager device operably coupled to the interface, the plurality of incoming requests having a common incoming transaction identifier and each incoming request associated with a different address in the data processing network (Dhamdhere [0062] Initially, data is received from a transmitting agent at a receiving agent (Operation 302). This initial data may include one or more data items (or a portion thereof) to be stored by the receiving agent, meta-data corresponding to the data items, header data, a notification, a message, an upload or file transfer request to the receiving agent and/or instructions or details relating to the request [0063] the received data includes a request and claim 4 transmitting each of the plurality of messages and claim 6 a same transaction identifier is included in each of the plurality of messages [0096] the data items are received via separate requests from different tenants (addresses))
It would have been obvious before the effective filing date of the claimed invention to combine the teachings of Bahis and Dhamdhere for the same reasons stated in claim 1.
Bahis nor Dhamdhere teach
in an identification (ID) diversifier circuit of the interface,
However Viola does teach
in an identification (ID) diversifier circuit of the interface (Viola [0128] In an embodiment, the remote system 21 may store the diversifier ID on its side. And during a transaction, the mobile application 18 may request the diversifier ID to the remote system 21 to generate the static key WB_KEK. In an embodiment, this generated static key WB_KEK is deleted after the computation of the cryptogram)
It would have been obvious before the effective filing date of the claimed invention to combine the teachings of Bahis, Dhamdhere and Viola, for the same reasons stated in claim 11.
As to claim 14, the combination of Bahis, Dhamdhere and Viola teach the network interface of claim 11, further comprising a tracker table for recording an order of incoming requests ((Dhamdhere [0021] the data item is being produced or transmitted in an order in which the data item is being stored or retrieved and Bahis [0019]-[0020]
It would have been obvious before the effective filing date of the claimed invention to combine the teachings of Bahis, Voila and Dhamdhere for the same reasons stated in claim 1.
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bahis, Dhamdhere and Jun et al. Patent No.: 9, 043,481.
As to claim 2, the combination of Bahis and Dhamdhere teach the method of claim 1, where generating the outgoing transaction identifier based on the address associated with the incoming request and the common incoming transaction identifier includes: masking or truncating the address to produce a modified address (Bahis [0018] the second address comprises at least one of the following the first address, a transaction identifier, a random number, an identifier of a system, an identifier of an access node);
combining the modified address and the common incoming transaction identifier (Bahis [0018] the second address comprises at least one of the following the first address, a transaction identifier, a random number, an identifier of a system, an identifier of an access node);
as the outgoing transaction identifier (Bahis [0018] the second address comprises at least one of the following the first address, a transaction identifier, a random number, an identifier of a system, an identifier of an access node);
Bahis nor Dhamdhere teach
to produce a hash argument; and
generating a hash value of the hash argument
However Jun does teach
to produce a hash argument (Jun claim 2 generating a token comprises utilizing a one-way hash function to generate the token where arguments for the hash function include: the unique ID for the transaction); and
generating a hash value of the hash argument (Jun claim 2 generating a token comprises utilizing a one-way hash function to generate the token where arguments for the hash function include: the unique ID for the transaction)
It would have been obvious before the effective filing date of the claimed invention to combine the teachings of Bahis and Dhamdere with Jun, because Jun teaches us claim 5 . An apparatus for controlling access to network content, comprising: a validator operatively configured to validate a voucher representing authorization to access network content at a publishing point is valid, wherein the voucher comprises a unique ID identifying a particular transaction through which access to network content has been granted.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bahis, Dhamdhere and Joo et al. (Pub. No.: 2019/0020735 A1).
As to claim 8, the combination of Bahis and Dhamdhere teach the method of claim 1,
Bahis nor Dhamdhere teach
further comprising: converting the incoming request from a first protocol to provide the outgoing request in a second protocol.
However Joo does teach
further comprising: converting the incoming request from a first protocol to provide the outgoing request in a second protocol (Joo [0143] Upon receipt of a response from the external electronic device in response to the connection request, the processor may change the protocol for use in communication from the first protocol 1010 to the second protocol 1020 (e.g., TCP/IP or UDP))
It would have been obvious before the effective filing date of the claimed invention to combine the teachings of Bahis and Dhamdhere with Joo, because Joo teaches us [0144] The processor may perform communication with the external electronic device using the second protocol 1020 and using connection information about the external electronic device for second protocol-based communication contained in the response.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bahis, Dhamdhere and Kashyap et al. (WO 2023/003533), herein Kashyap
As to claim 15, the combination of Bahis, Dhamdhere and Viola teach the network interface of claim 11,
Bahis, Dhamdhere nor Voila teach
further comprising a re-order buffer (ROB) for storing out-of-order responses to outgoing requests.
However Kashyap does teach
further comprising a re-order buffer (ROB) for storing out-of-order responses to outgoing requests (Kashyap [0038] The bridge 116 can include the reorder buffer 118 and a controller 210. The reorder buffer 118 can temporarily store in-order requests 202 of the clients 108 or responses received out-of-order from the memory controller 114. The bridge 116 can use the controller 210 to analyze the transaction requests from a particular client 108 and determine the degree of reorder possible for those transaction requests)
It would have been obvious before the effective filing date of the claimed invention to combine the teachings of Bahis, Dhamdhere and Viola with Kashyap, because Kashyap teaches us In this way, the bridge 116 can limit its use of buffer space in the reorder buffer 118 to that required to support the in-order degree for the particular client 108. In addition, by directly passing out-of-order requests 204 and portions of in-order requests 202 that can be carried out out-of-order, the controller 210 of the bridge 116 reduces the latency of the memory subsystem 110 in carrying out the transactions.
Allowable Subject Matter
Claims 3, 5-7, 9, 10-13, 16-18 and 20 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
Any inquiry concerning this communication or earlier communications from the examiner should be directed to AYANAH S GEORGE whose telephone number is (571)272-8880. The examiner can normally be reached 7:00 AM - 5:00 PM.
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, Hassan Phillips can be reached at 572-272-3940. 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.
AYANAH S. GEORGE
Primary Examiner
Art Unit 2467
/AYANAH S GEORGE/Primary Examiner, Art Unit 2467