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 .
DETAILED ACTION
Claims 1-20 are pending in this application.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 07//21/2025 is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-4, 6-12 and 14-20 are rejected under 35 U.S.C. 103 as being unpatentable over Toub et al (“Toub,” US 20110179038), Bohm et al (“Bohm,” US 20170090997) in view of Cimadamore et al (“Cimadamore,” US 20210133121) and further in view of Chan et al (“Chan,” US 20040261080).
Regarding claim 1, Toub discloses a data processing system for generating software components in a multithreaded processing environment that are capable of being executed in a thread-isolated manner to prevent data leakage across threads and that are linked together in a manner that enables the software components to share state, the data processing system comprising:
a processor; and (Toub, [0026] describes a processor)
a memory in communication with the processor, the memory comprising executable instructions that, when executed by the processor alone or in combination with other processors, cause the data processing system to perform functions of: (Toub, [0020] describes memory; [0026] describes a processor)
generating a face template for a type of thread-specific face of a component in a first thread of an application being executed in the multithread processing system; (Toub, [0003], describes generic holder instances containing thread static fields and dynamically parameterizes those holder instances; [0004] describes identifying type parameters and instantiating a generic holder object based on those type parameters [0015]-[0018], describe that .NET creates separate static fields for each closed generic type and uses different generic type parameter combinations to create distinct GenericHolder instantiations; [0026] with FIG 3 describe identifying type parameters and instantiates a generic holder object based on the identified parameters; [0027] with FIG 4 describes creating an array of dummy types, selects a type combination, and instantiates a corresponding generic holder)
initializing a first thread-specific face in the first thread using the face template in response, the first thread-specific face having a first thread-specific state; (Toub, FIG 4, step 404 describes initiating a thread local object, thereby generating a first instance; step 410, initiate a generic holder object based on selected type parameters. The generic holder contains a thread-local field configured to store per-thread data local to the first instance; [0027] describes that the thread-local object is instantiated to generate a first instance and that the generic holder’s field stores data local to the first instance; [0015]-[0018] describe using generic holder types with ThreadStatic static fields. A particular closed generic type is selected using type parameters; FIG 4, steps 408-410 describe identifying the type parameters and instantiate a generic holder object from that type; [0037]-[0038] describe a face template as a genericholder; [0016]-[0018] describe the first thread-specific face having a first thread-specific state as when ThreadStaticAttribute is applied to a static field, the field maintains a different value for ach thread that accesses it. Each thread has its own copy of s_value. Each ThreadLocal<T> instance also receives a unique parameterized generic holder, so the storage is both per-thread and per-instance. The first thread’s copy of s_value or the Boxed T stored in that field, is the claimed first thread-specific state)
initializing a first thread-local static variable for the first thread-specific face from a global variable in response to initialization of the first thread-specific face; (Toub, [0015]-[0018] describes that applying the .NET ThreadStaticAttribute to a static field causes the runtime to maintain a different value of that static field for each thread that access it; the field is declared static, the field is marked ThreadStatic; the first executing thread receives its own thread-specific instance or value of that static field; a second thread receives a different instance or value of the same declared static field; [0037]-[0038] describes a generic-holder definition where s_value is the static variable; [ThreadStatic] makes s_value thread-local; Boxed s_value stores the value associated with the current thread and the particular generic-holder type; [0017]-[0018], [0026]-[0028] describes a particular closed generic-holder type is generated or selected for a particular ThreadLocal<T> instance. The generic holder comprises ThreadStatic s_value. The first Thread has its own copy of s_value within that generic-holder type. The value is both per-thread and associated with the particular holder/ThreadLocal<T> instance; FIG 4, Steps 404-410 describes instantiating the first thread local object; select an index and generic type parameters. Instantiate the corresponding generic holder object. Use the holder’s thread-local field to store data local to the first instance and executing thread [this associates the first TLS static variable with the first proposed face]; FIG 6, [0053]-[0056] describe in response to the initialization of the first thread-specific face)
including a reference to the first thread-local static variable and a reference to the shared state in the first thread-specific face during initialization of the first thread-specific face in the first thread; (Toub, [0031]-[0035] describes an association between a ThreadLocal<T> instance and the generic holder that contains the thread-static field. Each ThreadLocal<T> instance includes a field such as HolderBase m_holder. Mholder identifies the generic holder associated with that particular ThreadLocal<T> instance. The generic holder contains the [ThreadStatic] field s_value; The boxed value stored in s_value includes an m_owner reference back to the holder; [0037]-[0038] describes GenericHolder<U,V,W> declares [ThreadStatic] private static Boxed s_value. The holder type defines the thread-local static variable associated with the first thread’s holder manifestation; [0056] and FIG 4 describe during initialization of the first thread-specific face; [0016]-[0018], [0053]-[0056] describe in the first thread)
initializing a second thread-specific face for the component in a second thread of the application based on the face template, the second thread-specific face having a second thread-specific state, (Toub, [0027], FIG 4, step 404 describes initiating a thread-local object, producing a first instance; steps 406-410 describe selecting an index, identifying generic type parameters, and instantiating the corresponding generic holder object; step 410 describes repeating the process for additional instances. The selected closed generic holder type GenericHolder<U,V,W> [face template]. A second per-thread manifestation of that generic-holder mechanism associated with another ThreadLocal<T> instance or another access thread [second thread-specific face]. Using the same generic holder class definition and type-parameter mechanism to create the second manifestation [based on the face template]; [0015]-[0018], describes ThreadStaticAttribute causes a static field to maintain a different value for eavery thread that accesses it. A first thread accessing s_value receives one thread-specific value. A second thread accessing the same declared field receives a separate value; [0053]-[0055] describes initialization occurring in a second thread; [0016]-[0018], [0037]-[0038] describes the second thread-specific face having a second thread-specific state)
initializing a second thread-local static variable for the second thread-specific face is initialized from the global variable in response to initialization of the second thread-specific face; (Toub, [0015]-[0018] describes applying ThreadStaticAttribute to a static field causes the runtime to maintain a different value of that field for each thread. The field is declared static, the field is marked [ThreadStatic]; the first thread receives one thread-specific copy; a second thread receives a separate thread specific copy of the same declared field; [0037]-[0038] describe the generic holder where the s_value is static; [ThresholdStatic] makes it local to each thread. The second accessing thread has its own distinct s_value; [0017]-[0018], [0027] describes each ThreadLocal<T> instance is assigned a parameterized generic holder. The holder contains the thread-static field. The same holder type provides a distinct value for each accessing thread. Figure 4, step 412 repeats the instantiation process for additional instances; [0053]-[0056] * Figure 6 describe in response to initialization of the second thread-specific face)
and including a reference to the second thread-local static variable and the reference to the shared state in the second thread-specific face during initialization of the second thread-specific face in the second thread, wherein the reference to the first thread-local static variable in the first thread-specific face and the reference to the second thread-local static variable in the second thread-specific face form a link between the first thread-specific face and the second thread-specific face that enables the first thread-specific face and the second thread-specific face to act together as a single component, (Toub, [0031]-[0035] describes each ThreadLocal<T> instance contains a field identified as HolderBase m_holder; m_holder identifies the generic holder associated with that ThreadLocal<T> instance. The generic holder contains the [ThreadStatic] s_value field. The Boxed object stored in s_value contains an m_ownerHolder reference identifying the holder to which that boxed value belongs); [0037]-[0038] describe GenericHolder<U,V,W> declares [ThreadStatic} private static Boxed s_value; where the second thread has its own distinct copy of s_value in the selected holder type which supplies the second TLS variable; [0027], Figure 4, steps 404-412; [0053]-[0056], FIG 6 describes during initialization of the second thread-specific face in the second thread; [0016]-[0018], [0031]-[0035] describe the reference to the first TLS variable and the reference to the second TLS variable to form a link between the first and second faces; [0017]-[0018], [0053]-[0055] describe to act together as a single component)
Toub fails to explicitly disclose generating a face template for a type of thread-specific face of a component in a first thread of an application being executed in the multithread processing system; initializing a first thread-specific face in the first thread using the face template in response, the first thread-specific face having a first thread-specific state; initializing a second thread-specific face for the component in a second thread of the application based on the face template, the second thread-specific face having a second thread-specific state; that enables the first thread-specific face and the second thread-specific face to act together as a single component; wherein the first thread-specific face and the second thread-specific face are each executed in a thread-isolated manner to prevent thread-specific faces from accessing thread-specific states of other thread-specific faces so that data leakage across threads is prevented
However, in an analogous art, Bohm discloses generating a face template for a type of thread-specific face of a component in a first thread of an application being executed in the multithread processing system; (Bohm, [0017]-[0019] describes per-thread manager instances belonging to one application extension)
initializing a first thread-specific face in the first thread using the face template in response, the first thread-specific face having a first thread-specific state; (Bohm, [0027]-[0029], FIG 2 discloses creating a thread-local manager for a particular thread in response to a request)
initializing a second thread-specific face for the component in a second thread of the application based on the face template, the second thread-specific face having a second thread-specific state (Bohm, [0017]-[0019], [0027]-[0029] describe a separate manager instance for another thread within the same application extension)
that enables the first thread-specific face and the second thread-specific face to act together as a single component (Bohm, [0017]-[0019], [0032]-[0033], Figures 1 and 3 describe multiple per-thread managers belonging to one application extension and exposing a common API and functionality)
wherein the first thread-specific face and the second thread-specific face are each executed in a thread-isolated manner to prevent thread-specific faces from accessing thread-specific states of other thread-specific faces so that data leakage across threads is prevented (Bohm, [0013]-[0015] disclose thread-local objects visible only to their corresponding threads)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bohm with Toub to include generating a face template for a type of thread-specific face of a component in a first thread of an application being executed in the multithread processing system; initializing a first thread-specific face in the first thread using the face template in response, the first thread-specific face having a first thread-specific state, initializing a second thread-specific face for the component in a second thread of the application based on the face template, the second thread-specific face having a second thread-specific state; that enables the first thread-specific face and the second thread-specific face to act together as a single component; wherein the first thread-specific face and the second thread-specific face are each executed in a thread-isolated manner to prevent thread-specific faces from accessing thread-specific states of other thread-specific faces so that data leakage across threads is prevented. One would have been motivated to provide a method and system for enhanced management of Java thread-local objects (Bohm, [0003]).
Toub and Bohm fail to explicitly disclose allocating shared state for use with all faces generated from the face template in response to the initialization of the first thread-specific face; and a reference to the shared state in the first thread-specific face during initialization of the first thread-specific face in the first thread; wherein the first thread-specific face and the second thread-specific face are each executed in a thread-isolated manner to prevent thread-specific faces from accessing thread-specific states of other thread-specific faces so that data leakage across threads is prevented.
However, in an analogous art, Cimadamore discloses allocating shared state for use with all faces generated from the face template in response to the initialization of the first thread-specific face; (Cimadamore, [0093]-[0097] describe a memory segment is represented by a shared memory segment view. The shared view refers to a memory segment that can be used by multiple threads. When a thread acquires the shared view, the system creates a new confined view for that thread. The newly created confined view retains a reference to the same underlying memory segment. The first confined view and later confined views are separate view objects. Each view corresponds to a different thread. All of the views reference the same physical memory segment. The common segment is available through all thread-specific views; FIG 5 shows multiple thread-confined views associated with one common memory segment and a common underlying segment with distinct views; FIG 9 shows the process of acquiring a shared view and creating a new confined view that refers to the same segment and shows creation of a new confined view when another thread acquires the shared view. Each newly generated view is tied back to the same segment [e.g. the confined views correspond to faces and the common underlying segment [the shared state])
and a reference to the shared state in the first thread-specific face during initialization of the first thread-specific face in the first thread (Cimadamore, [0093]-[0097] disclose a confined memory segment view retaining a reference to the underlying shared segment)
and wherein the first thread-specific face and the second thread-specific face are each executed in a thread-isolated manner to prevent thread-specific faces from accessing thread-specific states of other thread-specific faces so that data leakage across threads is prevented, (Cindamore, [0087]-[0094], Figures 8-9 describe a confined memory segment view is associated with a particular owning thread; when another thread acquires a shared view, a new confined memory segment view is created for that other thread; the first and second threads therefore operate through different confined view objects; both views may references the same underlying memory request; [0087]-[0092] describe each executed in a thread-isolated manner and to prevent thread-specific faces from accessing thread-specific states of other thread-specific faces)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Cimadamore with Toub and Bohm to include allocating shared state for use with all faces generated from the face template in response to the initialization of the first thread-specific face; and a reference to the shared state in the first thread-specific face during initialization of the first thread-specific face in the first thread; and wherein the first thread-specific face and the second thread-specific face are each executed in a thread-isolated manner to prevent thread-specific faces from accessing thread-specific states of other thread-specific faces so that data leakage across threads is prevented. One would have been motivated to provide a method and system for changing which threads are permitted to access a memory segment (Cimadamore, [0002]).
Toub, Bohm and Cimadamore fail to explicitly disclose initializing a second thread-local static variable for the second thread-specific face is initialized from the global variable in response to initialization of the second thread-specific face
However, in an analogous art, Chan discloses initializing a second thread-local static variable for the second thread-specific face is initialized from the global variable in response to initialization of the second thread-specific face (Chan, [0021]-[0024], [0043]-[0047], Figures 1 and 4 describe a first and second thread associated variables both interacting with one global variable through atomic exchange)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chan with Toub, Cimadamore and Bohm to include initializing a second thread-local static variable for the second thread-specific face is initialized from the global variable in response to initialization of the second thread-specific face. One would have been motivated to manage access to shared resources using control flow (Chan, [0001])
Regarding claim 2, Toub, Bohm, Cimadamore and Chan disclose the data processing system of claim 1,
Toub further discloses wherein the first thread-local static variable and the second thread-local static variable are each lazy-initialized, (Toub, [0015]-[0018] describes applying ThreadStaticAttribute to a static field causes the field to maintain a different value for every thread accessing it. The source-code field is declared once as a static field. The runtime provides a separate thread-local instance or value for the first thread. The runtime provides another separate thread-local instance or value for the second thread. The values are isolated by the thread; [0037]-[0038] describe the declaration [ThreadStatic} private static Boxed s_value; where the s_value is static; [ThreadStatic} causes each accessing thread to have its own distinct value. The first and second threads therefore have separate s_value values; [0053]-[0055], Pseudo Code Xi describes constructing a ThreadLocal<T> object with an initialization delegate such as ComputeValue. The delegate is invoked on each thread. The delegate initializes the value separately for that thread. Each thread’s value is initialized when that thread accesses the ThreadLocal <T> value; every accessing thread receives its own independently initialized value. When the thread first access the value, ComputeValue is invoked to initialize the first thread’s s_value; when the second thread first accesses the value, ComputeValue is separately invoked to initialize the second thread’s s_value; neither thread’s value needs to be computed until that that thread requests it [each variable being lazy-initiated]; also see [0049]-[0052] and Pseudo Codes IX-X and Figures 5-6)
Regarding claim 3, Toub, Bohm, Cimadamore and Chan disclose the data processing system of claim 2.
Toub further discloses wherein the face template includes a link to the shared state, (Toub, [0015]-[0018], [0026]-[0028], [0037]-[0038] describes a link which is the holder-reference relationship where a ThreadLocal<T> instance contains HolderBase m_holder; a m_holder identifies the generic holder associated with that ThreadLocal<T> instance; and the boxed thread-local value includes m_ownerHolder which identifies the holder that owns the value. This holder reference relationship establishes a link between the ThreadLocal<T> object, the selected generic holder and the per-thread boxed value)
Cimadamore further discloses wherein the face template includes a link to the shared state, (Cimadamore, [0093]-[0097] describes each created confined memory segment view retains a reference to the shared memory segment)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Cimadamore with Toub and Bohm to include wherein the face template includes a link to the shared state. One would have been motivated to provide a method and system for changing which threads are permitted to access a memory segment (Cimadamore, [0002]).
Regarding claim 4, Toub, Bohm, Cimadamore and Chan disclose the data processing system of claim 3.
Toub further discloses wherein the link is constructed using the first thread-local static variable and the second thread-local static variable such that the link ties the first thread-specific face and the second thread-specific face together to form a family of linked objects that act together as a single component, (Toub, [0015]-[0018] describes GenericHolder<U,V,W> contains one declared static field marked [ThreadStatic[. The runtime maintains a different value of that field for each thread. A first thread has a copy/value of s_value. A second thread has a second copy/value of s_value. Both per-thread values arise from the same declared field in the same generic holder type; [0031]-[0035] describes A ThreadLocal<T> instance that includes an m_holder reference to its generic holder. Each boxed per-thread value includes an m_ownerHolder, identifying the holder that owns that value. The first and second per-thread values are therefore associated with the same holder architecture and logical ThreadLocal<T> facility; [0017]-[0018] describes tying the thread-specific face and the second thread-specific face together; [0026]-[0028], Figures 3-4 to form a family of linked objects; [0030]-[0035], [0053]-[0056] that act together as a single component)
Bohm further discloses to form a family of linked objects that act together as a single component, (Bohm, [0017]-[0019] describe one application extension; multiple thread-local manager instances; one manager instance corresponding to each thread [family of linked objects]; [0027]-[0029] describe creation of a manager instance for a particular thread; [0032]-[0033] describe per-thread managers expose or implement common manager functionality and/or API [act together as a single unit])
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bohm with Toub to include to form a family of linked objects that act together as a single component. One would have been motivated to provide a method and system for enhanced management of Java thread-local objects (Bohm, [0003]).
Chan further discloses the link ties the first thread-specific face and the second thread-specific face together, (Chan, [0019]-[0024] describes a global variable 114. A first and second thread-associated variables 124 and 128. An atomic exchange of each thread-associated variable with the same global variable. Coordinated access to protected resource 110; [0043]-[0047] describe a global variable 406, first and second variables 414 and 416, atomic exchange instructions 418 and common managed resource 408)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chan with Toub, Cimadamore and Bohm to include the link ties the first thread-specific face and the second thread-specific face together. One would have been motivated to manage access to shared resources using control flow (Chan, [0001])
Regarding claim 6, Toub, Bohm, Cimadamore and Chan disclose the data processing system of claim 1.
Toub further discloses wherein the first thread-specific face and the second thread-specific face each have a thread-specific state that is separate from the shared state, (Toub, [0015]-[0018] describe that a static field is marked with ThreadStaticAttribute which maintains a different value for each threat that accesses it. The first thread has its own copy/value of the thread-static field. The second thread has a different copy/value of that same field. Those values are isolated by thread. The storage is also associated with the particular ThreadLocal<T> instance through the generic-holder mechanism; [0032], [0037]-[0039] describes GenericHolder<U,V,W) which declares [ThreadStatic] private static Boxed s_value where the boxed object constains the actual T value; the s_value is thread-static, the first and second threads have separate boxed values).
Cimadamore further discloses wherein the first thread-specific face and the second thread-specific face each have a thread-specific state that is separate from the shared state (Cimadamore, [0087]-[0097] describes distinct confined-view ownership and/or confinement state while each view separately references a common underlying segment)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Cimadamore with Toub and Bohm to include wherein the first thread-specific face and the second thread-specific face each have a thread-specific state that is separate from the shared state. One would have been motivated to provide a method and system for changing which threads are permitted to access a memory segment (Cimadamore, [0002]).
Regarding claim 7, Toub, Bohm, Cimadamore and Chan disclose the data processing system of claim 1.
Toub further discloses wherein the global variable includes a thread-safe handle that links the first thread-local static variable and the second thread-local static variable together, (Toub, [0015]-[0018], [0037]-[0038] describes a [ThreadStatic] s_value field having separate values for respective threads and associates those values with a common ThreadLocal<T> instance and a generic holder through an m_holder and m_ownerHolder. A thread-safe shared index-management structure is used to identify the relevant holder; also see [0031]-[0038], [0042]-[0048] and Figures 5-6)
Chan further discloses wherein the global variable includes a thread-safe handle that links the first thread-local static variable and the second thread-local static variable together, (Chan discloses in [0019]-[0024], [0043]-[0047] that a global variable 114/406 stores a pointer [thread-safe handle] to a protected to managed resource, with atomic exchange operations. First and Second thread-associated variables both exchange with the same global variable)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chan with Toub, Cimadamore and Bohm to include wherein the global variable includes a thread-safe handle that links the first thread-local static variable and the second thread-local static variable together. One would have been motivated to manage access to shared resources using control flow (Chan, [0001])
Regarding claim 8, Toub, Bohm, Cimadamore and Chan disclose the data processing system of claim 7.
Toub further discloses wherein the first thread includes application logic that generates the first thread-specific face and the thread-safe handle, (Toub, [0019]-[0028] descdribes per-thread/per-instance application logic that creates a first ThreadLocal<T> object, selects a unique index and generic type parameters, instantiates a corresponding generic holder containing [ThreadStatic] s_value, and stores a reference to the holder in t.m_holder. The holder/value manifestation [first thread-specific face]; also see [0031]-[0035], [0056], figures 1-2, 4, and 6 which disclose thread-safe index management structures)
Bohm further discloses wherein the first thread includes application logic that generates the first thread-specific face and the thread-safe handle, (Bohm, [0027]-[0029] discloses application-extension or thread-pool logic requesting and creating a manager for a particular thread)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Bohm with Toub to include wherein the first thread includes application logic that generates the first thread-specific face and the thread-safe handle. One would have been motivated to provide a method and system for enhanced management of Java thread-local objects (Bohm, [0003]).
Chan further discloses and the thread-safe handle, (Chan discloses in [0019]-[0024], [0043]-[0047] that a global variable 114/406 stores a pointer [thread-safe handle] to a protected to managed resource, with atomic exchange operations. First and Second thread-associated variables both exchange with the same global variable)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Chan with Toub, Cimadamore and Bohm to include and the thread-safe handle. One would have been motivated to manage access to shared resources using control flow (Chan, [0001])
Regarding claim 9, claim 9 is a directed to a method. Claim 9 is similar in scope to claim 1 and is therefore rejected under the same rationale.
Regarding claim 10, claim 10 is a directed to the method of claim 9. Claim 10 is similar in scope to claim 2 and is therefore rejected under the same rationale.
Regarding claim 11, claim 11 is a directed to the method of claim 10. Claim 11 is similar in scope to claim 3 and is therefore rejected under the same rationale.
Regarding claim 12, claim 12 is a directed to the method of claim 11. Claim 12 is similar in scope to claim 4 and is therefore rejected under the same rationale.
Regarding claim 14, claim 14 is a directed to the method of claim 9. Claim 14 is similar in scope to claim 6 and is therefore rejected under the same rationale.
Regarding claim 15, claim 15 is a directed to the method of claim 9. Claim 15 is similar in scope to claim 7 and is therefore rejected under the same rationale.
Regarding claim 16, claim 16 is a directed to the method of claim 15. Claim 16 is similar in scope to claim 8 and is therefore rejected under the same rationale.
Regarding claim 17, claim 17 is a directed to a non-transitory computer readable medium. Claim 17 is similar in scope to claim 1 and is therefore rejected under the same rationale.
Regarding claim 18, claim 18 is a directed to the non-transitory computer readable medium of claim 17. Claim 18 is similar in scope to claim 2 and is therefore rejected under the same rationale.
Regarding claim 19, claim 19 is a directed to the non-transitory computer readable medium of claim 18. Claim 19 is similar in scope to claim 3 and is therefore rejected under the same rationale.
Regarding claim 20, claim 20 is a directed to the non-transitory computer readable medium of claim 19. Claim 20 is similar in scope to claim 4 and is therefore rejected under the same rationale.
Claims 5 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Toub et al (“Toub,” US 20110179038), Bohm et al (“Bohm,” US 20170090997), Cimadamore et al (“Cimadamore,” US 20210133121) in view of Chan et al (“Chan,” US 20040261080) and further in view of Garthwaite et al (“Garthwaite,” US 7,954,100).
Regarding claim 5, Toub, Bohm, Cimadamore and Chan disclose the data processing system of claim 1.
Toub further discloses wherein the face template causes the first thread-specific face and the second thread-specific face to each have a compiler tag indicating that the first thread-specific face and the second thread-specific face cannot be used by other threads (Toub in [0015]-[0018], [0037]-[0038] describe a generic holder type containing a field marked with the compiler/runtime attribute [ThreadStatic], causing the field to have a distinct value for each accessing thread.)
Toub fails to explicitly disclose wherein the face template causes the first thread-specific face and the second thread-specific face to each have a compiler tag indicating that the first thread-specific face and the second thread-specific face cannot be used by other threads
However, in an analogous art, Garthwaite discloses wherein the face template causes the first thread-specific face and the second thread-specific face to each have a compiler tag indicating that the first thread-specific face and the second thread-specific face cannot be used by other threads (Garthwaite describes in Col, 3, Lines 5-35; Col. 4, Lines 27-64; using tagged references in which a tag or designated reference represented as a bit identifies the referenced object as thread-local. A compiler generated reference and barrier mechanism examines the tag and treats the reference differently from a globally shared reference, including detecting or processing the thread-local reference; also see Col. 5, Lines 47-57; Col. 6, Lines 29-66; Figures 2-6)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Garthwaite with Toub, Cimadamore, Bohm and Chan to include wherein the face template causes the first thread-specific face and the second thread-specific face to each have a compiler tag indicating that the first thread-specific face and the second thread-specific face cannot be used by other threads. One would have been motivated to provide a method and system for management of thread-local data (Garthwaite, Col. 1, Lines 7-8)
Regarding claim 13, Toub, Bohm, Cimadamore and Chan disclose the method of claim 9.
Toub further discloses wherein the face template causes the first thread-specific face and the second thread-specific face to each have a compiler tag indicating that the first thread-specific face and the second thread-specific face are not thread-safe, (Toub in [0015]-[0018], [0037]-[0038] describes a generic holder type containing a static field marked with the compiler/runtime attribute [ThreadStatic], which causes the field to maintain a separate value for each accessing thread)
Toub fails to explicitly disclose wherein the face template causes the first thread-specific face and the second thread-specific face to each have a compiler tag indicating that the first thread-specific face and the second thread-specific face are not thread-safe
However, in an analogous art, Garthwaite discloses wherein the face template causes the first thread-specific face and the second thread-specific face to each have a compiler tag indicating that the first thread-specific face and the second thread-specific face are not thread-safe (Garthwaite describes in Col, 3, Lines 5-35; Col. 4, Lines 27-64; using tagged references in which a tag or designated reference represented as a bit identifies the referenced object as thread-local. A compiler generated reference and barrier mechanism examines the tag and treats the reference differently from a globally shared reference, including detecting or processing the thread-local reference; also see Col. 5, Lines 47-57; Col. 6, Lines 29-66; Figures 2-6)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Garthwaite with Toub, Cimadamore, Bohm and Chan to include wherein the face template causes the first thread-specific face and the second thread-specific face to each have a compiler tag indicating that the first thread-specific face and the second thread-specific face are not thread-safe. One would have been motivated to provide a method and system for management of thread-local data (Garthwaite, Col. 1, Lines 7-8)
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JAMES J WILCOX whose telephone number is (571)270-3774. The examiner can normally be reached M-F: 8 A.M. to 5 P.M..
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, Luu T. Pham can be reached on (571)270-5002. 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.
/JAMES J WILCOX/Examiner, Art Unit 2439
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights