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 amendment filed on 6/22/2026. This action is made FINAL.
Claims 1-4 and 7-20 are pending and they are presented for examinations.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claim(s) 10-16, 18 and 20 is/are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 10 (similarly claims 12 and 18) recites the limitation “execute functionality associated with the remote procedure calls based on the identifier”. There is insufficient antecedent basis for this limitation in the claim. The examiner is unclear how “the identifier” is associated with multiple remote procedure calls or which remote procedure call of the remote procedure calls the identifier is associated with.
Claims 11-16 and 20 are rejected based on rejection of its corresponding dependent claim.
Response to Amendment
Applicant's arguments with respect to claims 1-4 and 7-20 have been considered but are moot in view of the new ground(s) of rejection.
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.
Claim(s) 1, 2, 4 and 7-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Achenson et al. (Pat 6477586) (hereafter Achenson) in view of Kumar et al. (Pub 20210117255) (hereafter Kumar).
As per claim 1, Achenson teaches:
A non-transitory, computer-readable medium comprising machine-readable instructions that, when the program code is executed on a processor of a requesting host, causes the processor to:
provide an interface for locally receiving remote procedure calls from a plurality of threads of a computer program; and
forward, upon receiving a remote procedure call from a thread of the computer program, the remote procedure call to a providing host that provides a functionality associated with the remote procedure call,
wherein the remote procedure call is forwarded to the providing host together with an identifier identifying the thread having issued the remote procedure call. ([Column 1 line 22-67], In multi-threaded, multi-process distributed systems, one characteristic function made available in the system is a remote procedure call (RPC) function. An RPC permits a process in the distributed system to request that a different process in the system carry out a function implemented in that second process and, return information to the process having originated the RPC request... it is typical that the thread and process originating an RPC request will make use of a central registry (or broker) which provides the identity of the process able to respond to the RPC to the process originating the RPC. [Column 7 line 21-37], The RPC message which is communicated from process 2A to process 3, therefore has an updated hConn value and an updated hQueue value. Process 3 can deal with the message in the same manner as process 2A dealt with the message. If process 3 is able to process the RPC request and create an RPC response message, that message is sent back to process 2A over the connection identified in the RPC message, in this case connection 92. The RPC response message, when received by process 2A will be directed to the queue identified by the hQueue variable in the RPC response message. The associated thread then resets the value of hConn and hQueue as stored in its local memory, to permit the message to be passed back to Process 1 over connection 90 to be received by the message thread of block 70 for transfer to the appropriate queue in Process 1 as indicated in the restored hQueue value of the RPC response message. [Column 8 line 3-15], As has been described above, each process must maintain a data structure which reflects which process is able to respond to a given RPC request. The data is stored locally in each process and because RPC messages are forwarded through the distributed system, it is possible for processes to notionally perform a function where, in fact, the function is performed by another process. In other words, it is not necessary to update the information as to which process handles a particular function, even when the structure of the system is changed, as long as the correct pointers are in place in the various processes to permit the RPC messages to be routed through the distributed system to ultimately reach the appropriate process and thread. [Column 7 line 49-62], For example, the distributed system of the invention may be included in a multi-threaded, multi-process distributed system in which the threads in the processes are not implemented with associated queues. In such a case, the remote procedure call messages will include identifiers which correspond directly to the appropriate threads, and not to queues related to the threads. Although the preferred embodiment of the invention describes the invention as implemented in a system which incorporates a queue for each thread this characteristic is not essential for the working of the invention. [Column 1 line 23-34], In multi-threaded, multi-process distributed systems, one characteristic function made available in the system is a remote procedure call (RPC) function. An RPC permits a process in the distributed system to request that a different process in the system carry out a function implemented in that second process and, return information to the process having originated the RPC request. [Column 6 line 48-63], In this manner, the RPC message is sent to process 2A from Process 1 and returned to Process 1 from process 2A.)
Although Achenson discloses RPC is forwarded/returned a thread of a providing host which originated/issued the RPC and a thread has a thread identifier.
Achenson does not explicitly disclose an identifier identifying the thread having issued the remote procedure call.
Kumar teaches an identifier identifying the thread having issued the remote procedure call. ([Paragraph 14], The guest content module 129 could then invoke a remote procedure call to pass the request for the content 117 to the host content module 126. [Paragraph 25], The request can include a unique identifier for the content 117 and/or an identifier of the host process 123 or virtual machine 121 that originated the request for content 117.)
It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Achenson wherein remote procedure calls (RPCs) are received, forwarded to a host which provides a functionality to process/execute the forwarded RPCs with corresponding thread information/generated identifier, into teachings of Kumar wherein a thread identifier identifying the thread/process having issued the RPC is forwarded to the providing host which originated the RPC, because this would enhance the teachings of Achenson wherein by including the identifier identifying the thread/process having issued the RPC, it allows the originating thread which issued the RPC to receive a corresponding content(s)/result(s) back for which the RPC was issued, using the identifier.
As per claim 2, rejection of claim 1 is incorporated:
Achenson teaches wherein the machine-readable instructions comprise instructions to generate the identifier for identifying the thread having issued the remote procedure call, and to forward the remote procedure call together with the identifier for identifying the thread. ([Column 1 line 22-67], In multi-threaded, multi-process distributed systems, one characteristic function made available in the system is a remote procedure call (RPC) function. An RPC permits a process in the distributed system to request that a different process in the system carry out a function implemented in that second process and, return information to the process having originated the RPC request... it is typical that the thread and process originating an RPC request will make use of a central registry (or broker) which provides the identity of the process able to respond to the RPC to the process originating the RPC. [Column 5 line 47-67], Each thread and queue has an associated identifier… [Column 7 line 49-67], In such a case, the remote procedure call messages will include identifiers which correspond directly to the appropriate threads… [Column 7 line 49-62], For example, the distributed system of the invention may be included in a multi-threaded, multi-process distributed system in which the threads in the processes are not implemented with associated queues. In such a case, the remote procedure call messages will include identifiers which correspond directly to the appropriate threads, and not to queues related to the threads. Although the preferred embodiment of the invention describes the invention as implemented in a system which incorporates a queue for each thread this characteristic is not essential for the working of the invention. [Column 1 line 23-34], In multi-threaded, multi-process distributed systems, one characteristic function made available in the system is a remote procedure call (RPC) function. An RPC permits a process in the distributed system to request that a different process in the system carry out a function implemented in that second process and, return information to the process having originated the RPC request. [Column 6 line 48-63], In this manner, the RPC message is sent to process 2A from Process 1 and returned to Process 1 from process 2A.))
Kumar also teaches ([Paragraph 14], The guest content module 129 could then invoke a remote procedure call to pass the request for the content 117 to the host content module 126. [Paragraph 25], The request can include a unique identifier for the content 117 and/or an identifier of the host process 123 or virtual machine 121 that originated the request for content 117.)
As per claim 4, rejection of claim 2 is incorporated:
Achenson teaches wherein the machine-readable instructions comprise instructions to derive the identifier from an identifier of a communication session being established between an operating system being used to execute the computer program and the providing host. ([Column 1 line 22-67], In multi-threaded, multi-process distributed systems, one characteristic function made available in the system is a remote procedure call (RPC) function. An RPC permits a process in the distributed system to request that a different process in the system carry out a function implemented in that second process and, return information to the process having originated the RPC request... it is typical that the thread and process originating an RPC request will make use of a central registry (or broker) which provides the identity of the process able to respond to the RPC to the process originating the RPC. [Column 5 line 47-67], Each thread and queue has an associated identifier… [Column 7 line 49-67], In such a case, the remote procedure call messages will include identifiers which correspond directly to the appropriate threads… [Column 1 line 60-67], In a distributed system where the numbers of channels (or sockets) is a constrained resource, it will be appreciated that the use of a communication channel (or socket) by each thread wishing to originate an RPC, will create resource allocation, or operating system overhead, problems for the distributed system. In addition, the use of a central broker or registry creates overhead problems for such a distributed system. [Column 5 line 57-67], Each thread and queue has an associated identifier (queue id) which is unique within the process in which the thread is found. In the example of the preferred embodiment the, queue id is referred to by the variable hQueue. As indicated above, each process may have one or more message receiver threads each which is responsible for receiving messages from connections made between the process and other processes in the distributed system. The dispatcher thread, as shown in blocks 100 and 102, in each process is responsible for passing an RPC request message to the appropriate available thread from the pool of worker threads within the process to permit the RPC message to be processed. Alternatively, the worker thread receiving the RPC message may indicate that message is not in the appropriate process within the distributed system to handle the RPC request and that the RPC message is to be forwarded to another process. [Column 7 line 21-37], The RPC message which is communicated from process 2A to process 3, therefore has an updated hConn value and an updated hQueue value. Process 3 can deal with the message in the same manner as process 2A dealt with the message. If process 3 is able to process the RPC request and create an RPC response message, that message is sent back to process 2A over the connection identified in the RPC message, in this case connection 92.)
As per claim 7, rejection of claim 1 is incorporated:
Achenson teaches wherein the machine-readable instructions comprise instructions to forward, upon receiving a response from the providing host in response to a remote procedure call, the response to the thread having issued the remote procedure call. ([Column 1 line 23-34], In multi-threaded, multi-process distributed systems, one characteristic function made available in the system is a remote procedure call (RPC) function. An RPC permits a process in the distributed system to request that a different process in the system carry out a function implemented in that second process and, return information to the process having originated the RPC request. The RPC is implemented by an RPC message being transmitted across the distributed system such that the responding process receives the RPC and takes the appropriate steps as defined by the RPC message.)
Kumar also teaches ([Paragraph 14], The guest content module 129 could then invoke a remote procedure call to pass the request for the content 117 to the host content module 126. [Paragraph 25], The request can include a unique identifier for the content 117 and/or an identifier of the host process 123 or virtual machine 121 that originated the request for content 117.)
As per claim 8, rejection of claim 1 is incorporated:
Achenson teaches wherein the remote procedure call is forwarded to a service scheduler of the providing host, and/or wherein responses received from the providing host are received from the service scheduler of the providing host. ([Column 1 line 10-34], Distributed computer systems involve different processes which may execute simultaneously. The processes may be found on physically distinct processors or the processes may be implemented on a single processor. In multi-threaded distributed systems, each process may run one or more threads. Such distributed multi-threaded, multi-process systems are well known, particularly in real time processing applications such as systems for telephone control and management. Multi-threaded, multi-process distributed systems raise timing, scheduling, queuing, synchronizing and interprocess/interprocessor communications issues which must be solved to ensure that the distributed system runs efficiently and effectively. In multi-threaded, multi-process distributed systems, one characteristic function made available in the system is a remote procedure call (RPC) function. An RPC permits a process in the distributed system to request that a different process in the system carry out a function implemented in that second process and, return information to the process having originated the RPC request. The RPC is implemented by an RPC message being transmitted across the distributed system such that the responding process receives the RPC and takes the appropriate steps as defined by the RPC message.)
Kumar also teaches ([Paragraph 14], The guest content module 129 could then invoke a remote procedure call to pass the request for the content 117 to the host content module 126. [Paragraph 25], The request can include a unique identifier for the content 117 and/or an identifier of the host process 123 or virtual machine 121 that originated the request for content 117.)
As per claim 9, rejection of claim 1 is incorporated:
Achenson teaches wherein the machine-readable instructions implement a function dispatcher for forwarding the remote procedure call to the providing host. ([Column 5 line 26-34], Within process 2A is illustrated a dispatcher thread and associated queue, shown in block 100. Process 3 is shown as having a dispatcher thread and queue in block 102… [Column 1 line 23-34], In multi-threaded, multi-process distributed systems, one characteristic function made available in the system is a remote procedure call (RPC) function. An RPC permits a process in the distributed system to request that a different process in the system carry out a function implemented in that second process and, return information to the process having originated the RPC request. The RPC is implemented by an RPC message being transmitted across the distributed system such that the responding process receives the RPC and takes the appropriate steps as defined by the RPC message.)
As per claim 10, Achenson teaches:
A non-transitory, computer-readable medium comprising machine-readable instructions that, when the program code is executed on a processor of a providing host, causes the processor to:
receive, from a requesting host requesting access to functionality being provided by the providing host, forwarded remote procedure calls, wherein the remote procedure calls are received together with a respective identifier identifying a thread having issued a respective remote procedure call; and
execute functionality associated with the remote procedure calls based on the identifier. ([Column 1 line 22-67], In multi-threaded, multi-process distributed systems, one characteristic function made available in the system is a remote procedure call (RPC) function. An RPC permits a process in the distributed system to request that a different process in the system carry out a function implemented in that second process and, return information to the process having originated the RPC request. The RPC is implemented by an RPC message being transmitted across the distributed system such that the responding process receives the RPC and takes the appropriate steps as defined by the RPC message… it is typical that the thread and process originating an RPC request will make use of a central registry (or broker) which provides the identity of the process able to respond to the RPC to the process originating the RPC. [Column 7 line 21-37], The RPC message which is communicated from process 2A to process 3, therefore has an updated hConn value and an updated hQueue value. Process 3 can deal with the message in the same manner as process 2A dealt with the message. If process 3 is able to process the RPC request and create an RPC response message, that message is sent back to process 2A over the connection identified in the RPC message, in this case connection 92. The RPC response message, when received by process 2A will be directed to the queue identified by the hQueue variable in the RPC response message. The associated thread then resets the value of hConn and hQueue as stored in its local memory, to permit the message to be passed back to Process 1 over connection 90 to be received by the message thread of block 70 for transfer to the appropriate queue in Process 1 as indicated in the restored hQueue value of the RPC response message. [Column 8 line 3-15], As has been described above, each process must maintain a data structure which reflects which process is able to respond to a given RPC request. The data is stored locally in each process and because RPC messages are forwarded through the distributed system, it is possible for processes to notionally perform a function where, in fact, the function is performed by another process. In other words, it is not necessary to update the information as to which process handles a particular function, even when the structure of the system is changed, as long as the correct pointers are in place in the various processes to permit the RPC messages to be routed through the distributed system to ultimately reach the appropriate process and thread. [Column 7 line 49-62], For example, the distributed system of the invention may be included in a multi-threaded, multi-process distributed system in which the threads in the processes are not implemented with associated queues. In such a case, the remote procedure call messages will include identifiers which correspond directly to the appropriate threads, and not to queues related to the threads. Although the preferred embodiment of the invention describes the invention as implemented in a system which incorporates a queue for each thread this characteristic is not essential for the working of the invention. [Column 1 line 23-34], In multi-threaded, multi-process distributed systems, one characteristic function made available in the system is a remote procedure call (RPC) function. An RPC permits a process in the distributed system to request that a different process in the system carry out a function implemented in that second process and, return information to the process having originated the RPC request. [Column 6 line 48-63], In this manner, the RPC message is sent to process 2A from Process 1 and returned to Process 1 from process 2A.)
Although Achenson discloses RPC is forwarded/returned a thread of a providing host which originated/issued the RPC and a thread has a thread identifier.
Achenson does not explicitly disclose a respective identifier identifying a thread having issued a respective remote procedure call.
Kumar teaches a respective identifier identifying a thread having issued a respective remote procedure call ([Paragraph 14], The guest content module 129 could then invoke a remote procedure call to pass the request for the content 117 to the host content module 126. [Paragraph 25], The request can include a unique identifier for the content 117 and/or an identifier of the host process 123 or virtual machine 121 that originated the request for content 117.)
It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Achenson wherein remote procedure calls (RPCs) are received, forwarded to a host which provides a functionality to process/execute the forwarded RPCs with corresponding thread information/generated identifier, into teachings of Kumar wherein a thread identifier identifying the thread/process having issued the RPC is forwarded/received/returned to the providing host which originated the RPC, because this would enhance the teachings of Achenson wherein by including the identifier identifying the thread/process having issued the RPC, it allows the originating thread which issued the RPC to receive a corresponding content(s)/result(s) back for which the RPC was issued, using the identifier.
As per claim 11, rejection of claim 10 is incorporated:
Achenson teaches wherein the machine-readable instructions comprise instructions to execute the functionality associated with the remote procedure calls concurrently if threads having issued the remote procedure calls are different. ([Column 1 line 10-23], Distributed computer systems involve different processes which may execute simultaneously. [Column 4 line 20-30], Advantages of the present invention include a multi-threaded, multi-process distributed system in which a single communication channel between processes may be utilized to communicate RPC messages from different threads within the same process. Further advantages include a multi-threaded, multi-process distributed system which maintains the information relating to which process is appropriate to respond to a given RPC, within the originating process, rather than at a central broker or registry.)
As per claim 12, rejection of claim 10 is incorporated:
Achenson teaches wherein the machine-readable instructions comprise instructions to assign each remote procedure call to one of a plurality of thread queues based on the identifier, and to execute the functionality associated with the remote procedure calls using a thread that is associated with the respective thread queue. ([Column 5 line 26-67], As will be appreciated by those skilled in the art, the numbers of threads found in each process will vary depending on the application. The thread and queue pairs, in blocks 40, 42, 44 as shown in Process 1 are referred to as worker threads in the example of the preferred embodiment. Such threads are involved in the parallel processing of RPC request and response messages. Similarly the thread and queue pairs shown in blocks 46, 48, 50, 52, 54, 56, 58, 60 and 62 are worker threads and queues in the illustrated example of FIG. 2. A thread will be blocked, or suspend its operation, in waiting for the associated queue to receive a message. ach thread and queue has an associated identifier (queue id) which is unique within the process in which the thread is found. In the example of the preferred embodiment the, queue id is referred to by the variable hQueue.)
As per claim 13, rejection of claim 10 is incorporated:
Achenson teaches wherein the machine-readable instructions comprise instructions to allow concurrent execution of threads of different thread queues. ([Column 1 line 10-23], Distributed computer systems involve different processes which may execute simultaneously. [Column 4 line 20-30], Advantages of the present invention include a multi-threaded, multi-process distributed system in which a single communication channel between processes may be utilized to communicate RPC messages from different threads within the same process. Further advantages include a multi-threaded, multi-process distributed system which maintains the information relating to which process is appropriate to respond to a given RPC, within the originating process, rather than at a central broker or registry. [Column 5 line 26-67], As will be appreciated by those skilled in the art, the numbers of threads found in each process will vary depending on the application. The thread and queue pairs, in blocks 40, 42, 44 as shown in Process 1 are referred to as worker threads in the example of the preferred embodiment. Such threads are involved in the parallel processing of RPC request and response messages. Similarly the thread and queue pairs shown in blocks 46, 48, 50, 52, 54, 56, 58, 60 and 62 are worker threads and queues in the illustrated example of FIG. 2. A thread will be blocked, or suspend its operation, in waiting for the associated queue to receive a message. ach thread and queue has an associated identifier (queue id) which is unique within the process in which the thread is found. In the example of the preferred embodiment the, queue id is referred to by the variable hQueue.)
As per claim 14, rejection of claim 10 is incorporated:
Achenson teaches wherein the machine-readable instructions comprise instructions to provide responses to the requesting host after executing the respective functionality associated with the remote procedure calls. ([Column 7 line 21-37], The RPC message which is communicated from process 2A to process 3, therefore has an updated hConn value and an updated hQueue value. Process 3 can deal with the message in the same manner as process 2A dealt with the message. If process 3 is able to process the RPC request and create an RPC response message, that message is sent back to process 2A over the connection identified in the RPC message, in this case connection 92. The RPC response message, when received by process 2A will be directed to the queue identified by the hQueue variable in the RPC response message. The associated thread then resets the value of hConn and hQueue as stored in its local memory, to permit the message to be passed back to Process 1 over connection 90 to be received by the message thread of block 70 for transfer to the appropriate queue in Process 1 as indicated in the restored hQueue value of the RPC response message. [Column 1 line 23-34], In multi-threaded, multi-process distributed systems, one characteristic function made available in the system is a remote procedure call (RPC) function. An RPC permits a process in the distributed system to request that a different process in the system carry out a function implemented in that second process and, return information to the process having originated the RPC request. The RPC is implemented by an RPC message being transmitted across the distributed system such that the responding process receives the RPC and takes the appropriate steps as defined by the RPC message.)
As per claim 15, rejection of claim 10 is incorporated:
Achenson teaches wherein the remote procedure calls are received from a function dispatcher of the requesting host, and/or wherein responses provided after executing the respective functionality are provided to the function dispatcher of the requesting host. ([Column 5 line 26-34], Within process 2A is illustrated a dispatcher thread and associated queue, shown in block 100. Process 3 is shown as having a dispatcher thread and queue in block 102… [Column 1 line 23-34], In multi-threaded, multi-process distributed systems, one characteristic function made available in the system is a remote procedure call (RPC) function. An RPC permits a process in the distributed system to request that a different process in the system carry out a function implemented in that second process and, return information to the process having originated the RPC request. The RPC is implemented by an RPC message being transmitted across the distributed system such that the responding process receives the RPC and takes the appropriate steps as defined by the RPC message.)
As per claim 16, rejection of claim 10 is incorporated:
Achenson teaches wherein the machine-readable instructions implement a service scheduler for scheduling the execution of the functionality in response to the remote procedure calls. ([Column 1 line 10-34], Distributed computer systems involve different processes which may execute simultaneously. The processes may be found on physically distinct processors or the processes may be implemented on a single processor. In multi-threaded distributed systems, each process may run one or more threads. Such distributed multi-threaded, multi-process systems are well known, particularly in real time processing applications such as systems for telephone control and management. Multi-threaded, multi-process distributed systems raise timing, scheduling, queuing, synchronizing and interprocess/interprocessor communications issues which must be solved to ensure that the distributed system runs efficiently and effectively. In multi-threaded, multi-process distributed systems, one characteristic function made available in the system is a remote procedure call (RPC) function. An RPC permits a process in the distributed system to request that a different process in the system carry out a function implemented in that second process and, return information to the process having originated the RPC request. The RPC is implemented by an RPC message being transmitted across the distributed system such that the responding process receives the RPC and takes the appropriate steps as defined by the RPC message.)
As per claim 17, this is an apparatus claim corresponding to the non-transitory computer-readable medium claim 1. Therefore, rejected based on similar rationale.
As per claim 18, this is an apparatus claim corresponding to the non-transitory computer-readable medium claim 10. Therefore, rejected based on similar rationale.
As per claim 19, rejection of claim 17 is incorporated:
Achenson teaches A computer system comprising the apparatus of claim 17. ([Column 1 line 10-22], Distributed computer systems involve different processes which may execute simultaneously.)
As per claim 20, rejection of claim 18 is incorporated:
Achenson teaches A computer system comprising the apparatus of claim 18. ([Column 1 line 10-22], Distributed computer systems involve different processes which may execute simultaneously.)
Claim(s) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Achenson in view Kumar and further in view of Teal et al. (Pat 8950007) (hereafter Teal).
As per claim 3, rejection of claim 2 is incorporated:
Although Achenson in view of Kumar teaches the identifier associated with RPC which directly corresponds to an appropriate thread. (Achenson: [Column 7 line 41-62], As will be appreciated by those skilled in the art, this system may be used where the multi-threaded, multi process distributed system is implemented using different operating systems and communication protocols. For example, the distributed system of the invention may be included in a multi-threaded, multi-process distributed system in which the threads in the processes are not implemented with associated queues. In such a case, the remote procedure call messages will include identifiers which correspond directly to the appropriate threads, and not to queues related to the threads. Although the preferred embodiment of the invention describes the invention as implemented in a system which incorporates a queue for each thread this characteristic is not essential for the working of the invention.
Kumar [Paragraph 14], The guest content module 129 could then invoke a remote procedure call to pass the request for the content 117 to the host content module 126. [Paragraph 25], The request can include a unique identifier for the content 117 and/or an identifier of the host process 123 or virtual machine 121 that originated the request for content 117.)
Achenson and Kumar do not explicitly disclose wherein the machine-readable instructions comprise instructions to derive the identifier from an operating-system generated thread identifier of the thread.
Teal teaches wherein the machine-readable instructions comprise instructions to derive the identifier from an operating-system generated thread identifier of the thread. ([Column 18 line 13-35], Finally, because some operating systems and in particular, some Windows operating systems, support multithreaded execution, fields for recording ids of constituent threads are also provided. By capturing and maintaining such a dynamically varying set of runtime identifiers, the security infrastructure may interpose upon appropriate system calls and associate a particular interposed upon execution… [Column 24 line 1-16], thread identifiers used by the operating system to identify further processes (and associated dlls and threads) that execute code along code trajectory 651… [Column 26 line 32-60], Relative to the outbound interprocess communication, any of a variety of operations may be interposed upon, including in some embodiments, a socket or handle create operation, a remote procedure call (RPC) operation, etc. Security infrastructure 800 captures (819) transaction information (e.g., identifiers 821) for the outbound interprocess communication for inclusion (in the illustrated scenario) in process tracking cache 852 with the trust-changes (T) protection attribute 892 conveyed from entry 806. Any of a variety of identifiers (e.g., handles, descriptors, pathnames, CLSIDs, bindings, etc.) may be captured using interposition techniques described herein to facilitate identification (e.g., at 820) of a corresponding called component and/or transaction that is, or follows in the execution trajectory, an IPC target of the illustrated interprocess communication from calling component 801 to service 803.)
It would have been obvious to a person with ordinary skill in the art, before the effective filing date of the invention, to combine the teachings of Achenson and Kumar wherein remote procedure calls (RPCs) are received, forwarded to a host which provides a functionality to process/execute the forwarded RPCs with corresponding thread information/generated identifier which originated the RPCs, into teachings of Teal wherein the identifier is derived from an operating system generated thread identifier of the thread, because this would enhance the teachings of Achenson and Kumar wherein deriving/interposing an identifier from an operating system generated thread identifier, it allows the thread identifier(s) used by operating system to identify further processes. [Teal column 24]
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 DONG U KIM whose telephone number is (571)270-1313. The examiner can normally be reached 9:00am - 5:00pm.
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, Bradley Teets can be reached at 5712723338. 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.
/DONG U KIM/Primary Examiner, Art Unit 2197
Prosecution Insights