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 .
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) 1-17 and 19 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 1 (similarly claim 10) recites the limitation "the program code". There is insufficient antecedent basis for this limitation in the claim. The examiner is unclear which program code “the program code” is referring to.
Claim 1 (similarly claim 17) recites the limitation "one of the threads". There is insufficient antecedent basis for this limitation in the claim. The examiner is unclear if one of the threads are referring to the plurality of threads or some other threads of the computer program.
Claim 1 (similarly claims 2, 3, 6) recites the limitation "the thread". There is insufficient antecedent basis for this limitation in the claim. The examiner is unclear what thread, the thread is referring to.
Claim 5 (similarly claims 6, 11) recites the limitation "the threads". There is insufficient antecedent basis for this limitation in the claim. The examiner is unclear what threads, the threads are referring to.
Claim 6 recites the limitation “forward the remote procedure call”. There is insufficient antecedent basis for this limitation in the claim. The examiner is unclear if the remote procedure call is referring to the respective remote procedure call or some other remote procedure call.
Claim 7 recites the limitation "the respective thread". There is insufficient antecedent basis for this limitation in the claim. The examiner is unclear what thread, the respective thread is referring to.
Claim 8 recites “the forwarded remote procedure calls”. Claim 1 which claim 8 depends on only recites forwarding of single remote procedure call. The examiner is unclear exactly what is being referring to as “the forwarded remote procedure calls”. Furthermore, claim 8 recites “responses received”. The examiner is unclear how more than one response are received for one forwarded remote procedure call from claim 1.
Claims 2-9, 11-16, 19 are rejected based on rejection of its corresponding dependent claim.
Claim Rejections - 35 USC § 102
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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1, 2 and 4-20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Achenson et al. (Pat 6477586) (hereafter Achenson).
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 one of the threads of the computer program, the remote procedure call to a providing host that provides the functionality associated with the remote procedure call, wherein the remote procedure call is forwarded together with information on 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.)
As per claim 2, rejection of claim 1 is incorporated:
Achenson teaches wherein the machine-readable instructions comprise instructions to generate an 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…)
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 5, rejection of claim 1 is incorporated:
Achenson teaches wherein the machine-readable instructions comprise instructions to forward, upon receiving remote procedure calls from different threads, the remote procedure calls with information for distinguishing the threads having issued the remote procedure calls. ([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 49-67], In such a case, the remote procedure call messages will include identifiers which correspond directly to the appropriate threads…)
As per claim 6, rejection of claim 5 is incorporated:
Achenson teaches wherein the machine-readable instructions comprise instructions to generate, for each of the threads having issued a remote procedure call, an identifier for identifying the thread having issued the respective remote procedure call, and to forward the remote procedure call together with the respective identifiers 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 7 line 49-67], In such a case, the remote procedure call messages will include identifiers which correspond directly to the appropriate threads…)
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 respective thread having issued the remote procedure call having triggered the response. ([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 8, rejection of claim 1 is incorporated:
Achenson teaches wherein the forwarded remote procedure calls are 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.)
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 calls 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:
obtain, from a requesting host requesting access to functionality being provided by the providing host, forwarded remote procedure calls, wherein the remote procedure calls are forwarded together with information on a thread having issued the respective remote procedure call; and
execute functionality associated with the forwarded remote procedure calls based on the information on the thread having issued the respective 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. 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.)
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 forwarded remote procedure calls concurrently if the threads having issued the respective 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 forwarded remote procedure call to one of a plurality of thread queues based on the information on the thread having issued the respective remote procedure call, and to execute the functionality associated with the forwarded 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 forwarded 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 forwarded remote procedure calls are obtained 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 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 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) 3 is/are rejected under 35 U.S.C. 103 as being unpatentable over Achenson in view of Teal et al. (Pat 8950007) (hereafter Teal).
As per claim 3, rejection of claim 2 is incorporated:
Although Achenson teaches the identifier associated with RPC which directly corresponds to an appropriate thread. ([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.)
Achenson does not explicitly discloses 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 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 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
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